ADR-0014 carries superseded claims and duplicates a classification the runtime owns

Problem

ADR-0014 carries superseded claims that a literal reader will act on, and it duplicates a lane classification that runtime code actually owns. Both were exercised tonight: I built an analysis and a ticket recommendation on the stale text before checking the runtime map.

1. Superseded claims are not annotated as superseded

The 2026-05-23 (#11740) amendment states:

tenant-repo-sync | periodic, heavy | cloud-deployable | ... It is the mirror image of the local-only lanes: config-disabled in the local Neo-maintainer profile (which has no tenant repos), exactly as the local-only lanes are config-disabled in cloud.

and

This amendment blesses the architectural shape — it does not mark the pull-ingestion path production-deployable. Per #11740 AC4, the credential / token / env-var contract ... is specified by sub #11787 and is a hard prerequisite before tenant-repo-sync is marked production-ready.

Both are now false, and nothing in the document says so:

• "config-disabled in the local Neo-maintainer profile" predates the local Agent OS being replaced by the dockerized deployment. "Local" then meant a non-containerized maintainer machine, which no longer exists. ai/daemons/orchestrator/taskAuthority.mjs:109 classifies the lane containerPlane, and the dockerized local plane is the container plane — so the lane running there is correct, the exact opposite of what the text implies.
• "not production-deployable pending #11787" is superseded by #11790 (lane landed), #11791 (operator docs + health/telemetry), and #12052/#12053 (Day-0 milestone rewritten to first-class pull mode).

A reader arriving at the amendment list in order has no signal that the May entry no longer describes the system. The later 2026-07-30 (#16166) amendment replaces the cloud-vs-local axis with host-edge / container-plane, but does not retract the earlier per-lane text it invalidates.

2. The ADR duplicates a classification the code owns

§2.1 and every amendment maintain per-lane classification tables. The runtime source of truth is taskAuthority.mjs (TASK_AUTHORITY_BY_NAME / AUTHORITY_CLASSES_BY_PROFILE), projected there by #16166. Two copies of one fact, free to disagree — and they do: the ADR says a lane is config-disabled locally while the authority map says containerPlane.

This is the same defect class as the drift channel ADR-0019 removed for config leaves (one value, two resolvers). Here it is one classification, two documents.

Cost — measured, not hypothetical

Tonight (session 11695cce), working #16566, I:

1. read the May amendment as binding, concluded the lane should not be running on the canonical plane,
2. wrote that into a filed ticket body as the leading finding with "READ FIRST" framing,
3. had it corrected by the operator on the grounds of timing ("you quote the 11000 range while we are inside the 16000 range"),
4. then found taskAuthority.mjs:109 in one grep, which falsified the whole section.

A wrong recommendation was live in a PRIO-0 ticket. Had it been implemented, the response would have been to disable a lane that is correctly enabled.

Proposed fix

1. Annotate superseded claims in place. Each invalidated statement gets an inline forward-pointer to the amendment or ticket that superseded it. Append-only amendment history is fine; silently-false earlier text is not.
2. Stop duplicating per-lane classification. The ADR keeps the rationale and the decision vocabulary; per-lane authority classification points at taskAuthority.mjs as SSOT rather than restating it in a table that drifts. Where a table aids readability, mark it explicitly non-authoritative and generated-from / checked-against the runtime map.
3. Add a currency header. State the latest amendment date and that per-lane classification lives in the runtime map, so a reader knows within the first screen whether the body is current.
4. Consider a mechanical guard (own ticket if it grows): a check that every lane named in an ADR-0014 classification table exists in TASK_AUTHORITY_BY_NAME with a matching class. That converts this class of drift from prose discipline into a failing test. Note the substrate-accretion rule — if a guard lands, record its sunset condition.

Acceptance criteria

• Every superseded claim in ADR-0014's amendment history carries an inline pointer to what superseded it, verified for the two named above at minimum.
• Per-lane authority classification is not duplicated as authoritative prose; the ADR points at taskAuthority.mjs.
• A currency header names the latest amendment and the runtime SSOT.
• A reader following the document top-to-bottom cannot conclude tenant-repo-sync should be disabled on the dockerized plane.
• Decision on the mechanical guard recorded (implement, or defer with a reason).

Out of scope

• Re-deciding any lane's classification. This ticket makes the record accurate; it changes no runtime behavior.
• Other ADRs. If the same duplicate-classification pattern exists elsewhere, file separately rather than widening this.

Note on scope discipline

This is substrate work on a decision record, so it wants a reviewer who was not the author of tonight's mistake. Per the substrate-accretion rule, the net effect should be less authoritative prose, not more: removing a duplicated table beats adding a third one.

Related

• #16566 — the ticket whose body I had to correct; its body now carries an interim warning that this ticket should make unnecessary.
• #16166 — the host-edge / container-plane authority projection that superseded the cloud-vs-local axis.
• #11740 — the amendment carrying the two stale claims.
• #16556 — moved kbSync to the container plane, part of why both lanes now share a plane.

Authored by @neo-opus-vega (Claude Opus 5).