From d1e7ba19caad1dedd876ade17395ee019515c6dd Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Fri, 31 Jul 2026 18:06:18 -0500 Subject: [PATCH] docs(remediation): promote observe-the-property principle to charter; bank D-13 dual credential registries MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Charter gains a first-class principle per Mos: no write is done until the requested PROPERTY is observed; a success exit code is not evidence. Success output is designed to be believed — that is why the inert-gate class exists and why the P-WRAPPER tri-state is not optional. Recorded with its provenance: the orchestrator committed this exact error (D-12), and three of the session's twelve instances were its own. D-13: diagnosing D-12 found two parallel credential registries that can disagree. gitea-mosaicstack-mos-dt-0.token EXISTS, but tea has no mosaicstack login for that identity — so raw-API paths work while tea-dependent wrapper paths silently degrade. tea is not stale; the login does not exist. Capability declared authoritative by the token-file set does not govern the tea path. RM-04 must reconcile the registries (or assert agreement at startup, with a must-fail control). RM-50's pre-dispatch check must verify capability for the path actually used. Co-Authored-By: Claude Opus 5 (1M context) --- docs/remediation/MISSION.md | 18 ++++++++++++++++++ docs/remediation/TASKS.md | 27 +++++++++++++++++++++++++++ 2 files changed, 45 insertions(+) diff --git a/docs/remediation/MISSION.md b/docs/remediation/MISSION.md index 2065267d..682eda5e 100644 --- a/docs/remediation/MISSION.md +++ b/docs/remediation/MISSION.md @@ -10,6 +10,24 @@ Convert the 15 accepted postmortem remediation proposals into a working, **dogfo **North star:** anything with a deterministic right answer moves OUT of the LLM into a deterministic gate/program; the LLM handles only genuine judgment. +### First-class principle — observe the property, not the exit code + +> **No write is done until the requested PROPERTY is observed. A success exit code is not evidence.** +> +> **Success output is designed to be believed.** That is the whole reason the inert-gate class exists +> and why P-WRAPPER-001's tri-state (`verified` / `written-unverified` / `failed`) is not optional. The +> failure is not carelessness — a green is _engineered_ to be trusted, so trusting it is the default +> behaviour of a competent operator, not a lapse. +> +> Promoted to the charter by Mos (2026-07-31) after the orchestrator committed this exact error: a +> `--draft` flag was silently dropped by a wrapper fallback that still exited 0, and the PR was reported +> as a draft on the strength of the exit code rather than an observed `draft: true` (D-12). Twelve +> failure instances were banked in that session; **three of them were the orchestrator's own.** That +> ratio is the point — the mechanism must catch the mechanic too, or it is not a mechanism. +> +> Operationally: after any write, read back the property you required. Applies to gates, wrappers, PR +> flags, commit authorship, file installs, and message delivery alike. + ## Decision record (authoritative, immutable) - **15/15 proposals decided: 13 accept, 2 modify (P-AUTHORITY-001, P-INBOX-001), 0 reject.** diff --git a/docs/remediation/TASKS.md b/docs/remediation/TASKS.md index 54a436f0..09517924 100644 --- a/docs/remediation/TASKS.md +++ b/docs/remediation/TASKS.md @@ -93,6 +93,33 @@ and must not be cited as merge evidence. Rely on reviewer clearance + real CI. Three independent live instances in a single session — format gate, agent context reset, queue guard — is the class confirmed, not anecdote. +### D-13 — two credential registries that can disagree (why the `--draft` fallback fired at all) + +Diagnosing D-12's root cause surfaced a distinct defect. There are **two parallel credential +registries**, and capability in one does not imply capability in the other: + +| registry | contents for identity `mos-dt-0` on `mosaicstack` | +| ------------------------------------------------------ | -------------------------------------------------------------------------------------------- | +| token files — `~/.config/mosaic/secrets/gitea-tokens/` | `gitea-mosaicstack-mos-dt-0.token` **EXISTS** | +| `tea login list` | **NO** `mosaicstack` login for `mos-dt-0` (only `mosaicstack-mos` and `mosaicstack-rev-974`) | + +So `get_gitea_token` succeeds and every raw-API path works, while every **tea-dependent** wrapper path +fails its login validation and silently degrades to the API fallback — which is exactly what dropped +`--draft`. **tea is not "stale"; the login simply does not exist for that identity.** + +This matters beyond one flag: capability was declared authoritative by the token-file set (D-11b), but +that registry does not govern the tea path. A seat can be _fully provisioned_ by the authoritative +registry and still lose functionality with no error — only a warning, and only on the degraded path. + +**Requirements.** RM-04 (activation coherence): the two registries must be reconciled — one source of +truth, or a startup check asserting they agree, with a must-fail control proving disagreement is +detected. RM-50: the pre-dispatch capability check must verify capability for the **path actually +used**, not merely token-file presence. + +**Confirmed working despite the gap** (so this is degradation, not outage): pushes, `pr-merge.sh`, +PR/issue creation via API fallback, comment posting, and all reads. Impact is confined to +tea-only features — `--draft`, `--labels`, `--milestone`. + ### D-12 — a requested SAFETY flag was silently degraded, and I did not check I created PR #1027 with `pr-create.sh ... -d` (draft) because it carries **partial, unproven work**.