docs(remediation): promote observe-the-property principle to charter; bank D-13 dual credential registries

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) <[email protected]>

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.**

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**.