ward-kdl-write signoz tier needs an env-auth override for in-container broker use (mirror forgejo #331) #341

New issue

Closed

opened 2026-06-25 18:04:57 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-25 18:04:57 +00:00

Owner

What

The signoz write tier (cmd/ward-kdl/ward-kdl-write/ward-kdl.signoz.write.guardfile.kdl, landed in ward#338) inherits the signoz read root's auth, which resolves the SigNoz API key from SSM (/coilysiren/signoz-ser8/api-token). That is correct for native/host use.

But the root credential broker (ward#329) shells write-tier binaries in-container, where there is no SSM and no AWS. So the moment the broker grows a signoz-write path - or anything runs ward-kdl-write ops signoz <verb> inside a warded/explore container - the inherited SSM auth will not resolve.

Fix (when signoz-write is actually brokered, not before)

Mirror what forgejo's write tier already does (ward#331): have the signoz write tier override the inherited SSM auth with an env-sourced one, e.g. value env "SIGNOZ_API_KEY", so the in-container broker can seed the key into the subprocess env (env, never argv). auth is a singleton, so the override is write-tier-only - read and admin stay SSM for host use, exactly as forgejo split them.

This is not needed yet: nothing brokers signoz-write today, and the foundation run deliberately left the signoz write auth as inherited-SSM. File it so the dependency is visible when Phase-2 context selection wires signoz into the broker.

References

ward#338 (the run that surfaced this in its retrospective), ward#331 (the forgejo write-tier env-auth override this mirrors), ward#329 (the broker that shells write tiers in-container), ward#339 (the tier-migration epic - this is a Phase-2 context-selection dependency).

## What The signoz **write** tier (`cmd/ward-kdl/ward-kdl-write/ward-kdl.signoz.write.guardfile.kdl`, landed in ward#338) inherits the signoz **read** root's auth, which resolves the SigNoz API key from **SSM** (`/coilysiren/signoz-ser8/api-token`). That is correct for native/host use. But the root credential broker (ward#329) shells **write-tier** binaries **in-container**, where there is no SSM and no AWS. So the moment the broker grows a signoz-write path - or anything runs `ward-kdl-write ops signoz <verb>` inside a warded/explore container - the inherited SSM auth will not resolve. ## Fix (when signoz-write is actually brokered, not before) Mirror what forgejo's write tier already does (ward#331): have the signoz **write** tier **override** the inherited SSM `auth` with an env-sourced one, e.g. `value env "SIGNOZ_API_KEY"`, so the in-container broker can seed the key into the subprocess env (env, never argv). `auth` is a singleton, so the override is write-tier-only - read and admin stay SSM for host use, exactly as forgejo split them. This is **not needed yet**: nothing brokers signoz-write today, and the foundation run deliberately left the signoz write auth as inherited-SSM. File it so the dependency is visible when Phase-2 context selection wires signoz into the broker. ## References ward#338 (the run that surfaced this in its retrospective), ward#331 (the forgejo write-tier env-auth override this mirrors), ward#329 (the broker that shells write tiers in-container), ward#339 (the tier-migration epic - this is a Phase-2 context-selection dependency).

coilysiren added the

headless

labels

2026-07-01 04:29:36 +00:00

coilyco-ops commented

2026-07-01 04:41:23 +00:00

Member

🛫 ward pre-flight: NO-GO

ward agent engineer --driver claude ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

issue explicitly defers the fix ("not needed yet... not before"); it's a Phase-2 dependency-tracking record with no code deliverable to merge today — a human should confirm whether any implementation is wanted now.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent engineer --driver claude <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

Context to front-load: The signoz guardfile tiers and the auth/value env/SSM override schema — cmd/ward-kdl/ward-kdl-write/ward-kdl.signoz.write.guardfile.kdl plus the read/admin roots it inherits from, and the forgejo write-tier precedent this mirrors (ward#331's env-auth split). Supporting conventions: docs/ward-kdl.md, docs/ward-kdl-surface.md, docs/ward-kdl-in-ward.md for the guardfile generator, and the broker wiring from ward#329. I would read each of these in the clone before any edit — but see the blocker below, which is about whether to edit at all, not how.

The decisive problem is that this issue explicitly instructs not to implement the fix yet: "Fix (when signoz-write is actually brokered, not before)" and "This is not needed yet... File it so the dependency is visible when Phase-2 context selection wires signoz into the broker." The deliverable of this issue is the filed tracking record itself — a Phase-2 dependency marker — not a code change. An unattended run told to carry it "to merge" has no valid mergeable action: doing nothing leaves nothing to merge, and implementing the env-auth override now directly violates the issue's own "not before" gate and would land auth wiring for a broker path that doesn't exist yet. That is a genuine intent fork a human must resolve (close-as-tracked vs. defer to Phase-2), not a reversible default I should pick.

NO-GO: issue explicitly defers the fix ("not needed yet... not before"); it's a Phase-2 dependency-tracking record with no code deliverable to merge today — a human should confirm whether any implementation is wanted now.

Posted automatically by ward agent engineer --driver claude pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent engineer --driver claude` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > issue explicitly defers the fix ("not needed yet... not before"); it's a Phase-2 dependency-tracking record with no code deliverable to merge today — a human should confirm whether any implementation is wanted now. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent engineer --driver claude <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> **Context to front-load:** The signoz guardfile tiers and the `auth`/`value env`/SSM override schema — `cmd/ward-kdl/ward-kdl-write/ward-kdl.signoz.write.guardfile.kdl` plus the read/admin roots it inherits from, and the forgejo write-tier precedent this mirrors (ward#331's env-auth split). Supporting conventions: `docs/ward-kdl.md`, `docs/ward-kdl-surface.md`, `docs/ward-kdl-in-ward.md` for the guardfile generator, and the broker wiring from ward#329. I would read each of these in the clone before any edit — but see the blocker below, which is about *whether* to edit at all, not *how*. The decisive problem is that this issue explicitly instructs **not to implement the fix yet**: "Fix (when signoz-write is actually brokered, not before)" and "This is **not needed yet**... File it so the dependency is visible when Phase-2 context selection wires signoz into the broker." The deliverable of this issue is the *filed tracking record itself* — a Phase-2 dependency marker — not a code change. An unattended run told to carry it "to merge" has no valid mergeable action: doing nothing leaves nothing to merge, and implementing the env-auth override now directly violates the issue's own "not before" gate and would land auth wiring for a broker path that doesn't exist yet. That is a genuine intent fork a human must resolve (close-as-tracked vs. defer to Phase-2), not a reversible default I should pick. NO-GO: issue explicitly defers the fix ("not needed yet... not before"); it's a Phase-2 dependency-tracking record with no code deliverable to merge today — a human should confirm whether any implementation is wanted now. </details> --- Posted automatically by `ward agent engineer --driver claude` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilysiren closed this issue

2026-07-01 05:35:01 +00:00