coulomb/ops-mason
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

MASON-WP-0004-T01 done: founder rulings on tenant conflict and unclear paths

Browse source 
A: coulomb as approved; four infotech hall-of-helix values move there as
part of MASON-WP-0005-T04. B1 retire duplicate activity-core/default entry,
B2 forgejo-mailer -> rapp-forgejo, B3 target-revenue deferred.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 327203@bnt-lap001
Assistant-Session: 55028ae3-4914-4bd1-8f5c-815f3527aef0
This commit is contained in:
tegwick 2026-10-09 11:02:47 +02:00
parent 9b3ec41f0e
commit cd6c61d034
3 changed files with 35 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/credential-owner-proposals-2026-10-09.md
View file

@ -28,12 +28,30 @@ Question for the founder: build the lane at `coulomb` and move the four values
there in one attended step (then destroy the `infotech` copies), or amend the
approved plan to the `infotech` path where the values already are?
**Ruling (founder, 2026-10-09): `coulomb` as approved.** The four values move
to `platform/workloads/coulomb/fluid-telegram/hall-of-helix/` in one attended,
output-free step (railiance-platform helper, same technique as the
tenant-engine seed: CAS 0 at the target, verify by version, then delete the
`infotech` copies' metadata). fluid-telegram repoints its refs to `coulomb`.
## B. Genuinely unclear — founder ruling or owner answer needed
1. `platform/workloads/activity-core/default/llm-connect-provider-secrets` — No document names it. Same secret name as `activity-core/llm-connect/llm-connect-provider-secrets` (CCR-2026-0003), v1 from 2026-06-18: a superseded first placement? Question: is anything still reading it, or can it be retired?
2. `platform/workloads/forgejo/forgejo-mailer` — No document names it. Question: is this the Forgejo SMTP credential, who owns it (railiance-platform as Forgejo operator?), and what reads it?
3. `platform/workloads/target-revenue/runtime-secrets` — No document names it. Question: which repo owns target-revenue, and is the workload still deployed?
**Rulings (founder, 2026-10-09):**
1. `activity-core/default/llm-connect-provider-secrets`: **retire** as the
duplicate of `activity-core/llm-connect/llm-connect-provider-secrets`. No
source in railiance-platform, activity-core or the ops-warden catalog refers
to it (checked 2026-10-09). Before the founder-run delete, confirm no live
policy grants the path.
2. `forgejo/forgejo-mailer`: owner **rapp-forgejo** (stub repo created by the
founder; it is where Forgejo's deployment and credentials belong).
3. `target-revenue/runtime-secrets`: **deferred** — outdated; picked up later
with target-revenue. Listed here as unknown on purpose; T02/T03 skip it.
## C. Documented — owner proposed from existing records
| Path | Version, last write | Proposed owner | Evidence |

11
workplans/MASON-WP-0004-credential-inventory-descriptions.md
View file

@ -49,10 +49,8 @@ read, and `ops-mason-build` cannot read one.
```task
id: MASON-WP-0004-T01
status: wait
needs_human: true
status: done
decision_id: e9f44beb-ad15-4285-8996-1e66d312fe59
blocking_reason: "Inventory and owner proposals done 2026-10-09 (docs/credential-owner-proposals-2026-10-09.md). Founder rules on section A (fluid-telegram tenant) and section B (three unclear paths)."
priority: medium
state_hub_task_id: "5bda75f2-f780-579e-9d44-cc4011662b9a"
```
@ -78,6 +76,13 @@ catalog or CCR), 3 genuinely unclear (`activity-core/default/llm-connect-provide
fluid-telegram entries under tenant `infotech` that conflict with the approved
MASON-WP-0005 plan (`coulomb`). Waiting on the founder's ruling for A and B.
2026-10-09 done: founder ruled. A: `coulomb` as approved, the four values move
there (MASON-WP-0005). B1: retire the duplicate `activity-core/default/...`
entry (founder-run delete via railiance-platform after a live no-grant check).
B2: `forgejo/forgejo-mailer` belongs to the new `rapp-forgejo` repo. B3:
`target-revenue/runtime-secrets` deferred as outdated. Every path now has a
proposed owner or an explicit reason, which is T01's acceptance.
## Describe the paths whose purpose is already documented
```task

10
workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md
View file

@ -182,7 +182,7 @@ id: MASON-WP-0005-T04
status: wait
depends_on: [MASON-WP-0005-T03]
blocked_on: human
blocking_reason: "HOLD: four hall-of-helix values already exist under platform/workloads/infotech/ (written 2026-10-07, undocumented); founder must rule coulomb+move or amend to infotech (docs/credential-owner-proposals-2026-10-09.md section A) before apply. Plan approved 2026-10-09. Writes are founder-applied through railiance-platform's per-path applier (RPF-WP-0035-T03, attended provisioning decision 62aa95e4), including the agent read-boundary denies; ops-mason verifies afterwards."
blocking_reason: "Founder ruled coulomb (2026-10-09): railiance-platform prepares the silent move of the four infotech values plus the lane apply. Plan approved 2026-10-09. Writes are founder-applied through railiance-platform's per-path applier (RPF-WP-0035-T03, attended provisioning decision 62aa95e4), including the agent read-boundary denies; ops-mason verifies afterwards."
priority: high
state_hub_task_id: "0e3d1333-ffc3-5f67-8528-50a9551c4949"
```
@ -197,6 +197,14 @@ The redaction-salt path grants `create,read` only. It does not grant `update`,
first write is therefore an attended, separately approved platform action, not
a provisioner capability.
2026-10-09: four values already sit at
`platform/workloads/infotech/fluid-telegram/hall-of-helix/` (written
2026-10-07, operator-session v4). Founder ruling: keep `coulomb` as approved
and move them. The move is part of this build: one attended, output-free
platform-admin step that writes each entry at the `coulomb` path with CAS 0,
verifies versions, then deletes the `infotech` metadata, so `redaction-salt`
keeps its value and stays write-once. fluid-telegram repoints its refs.
## Verify capabilities and record metadata-only evidence
```task