Orchestrata Ultimate › Plans › system-analysis-master

Orchestrata — master system analysis

Source: plans/system-analysis-master.md at 8a2cb42ad · last changed 2026-08-23 · first committed 2026-08-23 · 1639 lines.

Prose pending.

Plan text

Orchestrata — master system analysis

Living document. Generated from analysis/register.json; every analysis round appends to the register and this file is re-rendered. Do not hand-edit — an edit here is lost on the next round and silently disagrees with the evidence it cites.

0. Document control

Round log

Id scheme. Findings carry a global OA-NNN id. Agent-local ids are kept only as provenance (R1·GATE-03), because the per-agent id spaces collide — two round-2 lenses independently minted GS-01…GS-14. That is the same two registers, one id space defect this analysis found in the project's ADR registers, so the report does not repeat it.

Verification coverage actually achieved. Measured from the run journals, not asserted. An agent that died leaves its findings unverified, and the report has to say so rather than present them as vetted.

Verification states. confirmed = an independent domain coordinator re-verified it and promoted it. refuted = a coordinator rejected it, with the reason recorded. unverified = no coordinator ruling matched it yet — not a claim that it is wrong.

1. Verdict

37 FATAL · 275 MAJOR · 197 MINOR · 57 INFO

256 independently confirmed · 288 awaiting a coordinator ruling · 22 refuted and retained as a record.

Every domain that reported returned FAILING. The deployed bytes are correct — the production checkout is git-clean at the pushed commit, every unit file is byte-identical, and every daemon runs from the production venv. What fails is the layer that is supposed to notice when they stop being correct.

2. Systemic patterns — the highest-value output

Individual defects are cheap to fix and cheap to re-introduce. These are the shapes that recur across unrelated subsystems; each one predicts defects nobody has looked for yet.

P1. The oracle that cannot fail: a verdict derived from a field the producer never writes, an exit code the checker cannot set, or a stream the parser cannot read. The check is authored against the happy path and accepted because it prints PASS on a tree already believed good.

P2. Registration mistaken for wiring: an artifact exists, is executable, is deployed, and is named in a manifest — and nothing invokes it.

P3. The scope-narrowing default: a checker whose default argument excludes the root where the violations live, reporting a ratio whose denominator was derived from what it chose to look at.

P4. Fork-then-diverge: one capability, two implementations, and every path-keyed reference bound to whichever copy the author had open.

P5. Bare python / python3 in an invocation string: the verdict is decided by PATH, and the resulting ModuleNotFoundError is swallowed.

P6. Two authorities, no supersession path: the correcting decision is recorded somewhere the reader of the wrong document cannot see.

P7. Fail-open by default in the guard layer: a guard that cannot evaluate its input allows, and the allow is indistinguishable from a real pass.

P8. The hand-maintained inventory living beside a generated one, with no mechanical link and no completeness check — so every new gate, spec, package or script silently widens the gap.

2b. Strongest evidence — findings two or more independent lenses reached separately

These agents did not see each other's work. Independent convergence is the single best signal in the corpus, and it is where remediation should start.

3. FATAL register — all 37

Write Sinks, CI & Dating

OA-003 — .github/workflows/ci.yml has never been runnable: 12 gate scripts invoked nowhere else, committed the same day the repo went GitLab-only

🔴 FATAL · dead · ✅ confirmed · evidence: measured · state: static-source · corroborated ×2

The workflow declares 24 named steps, 19 of them checks, and invokes 13 gate scripts. Diffing its script list against .gitlab-ci.yml's shows 12 scripts that exist ONLY in the unrunnable GitHub workflow: ast_report.py, audit_test_purity.py, check_async_await.py, code-review.py, gate.py, gen_intent_lexicon.py, gen_level0.py, kg_schema.py, pyright_ratchet.py, run_tests_threadpool.py, serialize_codebase_ast.py, validate_ci.py. These cover the Prolog gate, the Level-0 context drift gate, canonical KG schema conformance, the intent-lexicon drift gate, the test-purity gate, the traceability ratchet, the async-correctness gate and both pyright ratchets — the entire mechanised half of this project's rulings. None has an automatic runner. Round 1 counted '8 further checks'; the measured figure is 19 steps / 12 orphaned scripts.

When it appeared. NEVER WIRED — 134 days. Both CI definitions were committed on 2026-04-11; the GitLab one explicitly "for GitLab", and the remote has been GitLab-only for the whole of recorded history. The GitHub workflow has been continuously maintained since — its last touch is 12e56bd3 on 2026-08-18, and it accumulated steps at 3c25acc6 / d3222032 (2026-08-16, pyright ratchets) — so 134 days of edits were made to a file that has never executed once. No commit records a rationale for keeping it.

Proposed fix. Port the 12 orphaned gate scripts into .gitlab-ci.yml (or into scripts/gates.py invoked from one GitLab job) and delete .github/workflows/ci.yml. Keeping it is worse than deleting it: every future contributor adding a check there believes they have wired enforcement, which is systemic pattern #2 with a 134-day track record.

Origin: R2·H-03, R1·DOCS-TRUTH-009 · Files: ast_report.py, audit_test_purity.py, check_async_await.py, code-review.py, docs/LEVEL0.md, gate.py

OA-014 — 120 consecutive total CI failures produced zero signal — the only automatic CI verification checks the YAML document, never the pipeline

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

Nothing in this repository reads pipeline status. The validate-ci gate — the project's sole automatic verification touching CI — parses .gitlab-ci.yml and reports 'All 14 CI validation gates passed' while every pipeline that file produces has failed for 12 days. scripts/validate_ci.py:399 binds ci_file = repo_root / ".gitlab-ci.yml": its oracle is the document's shape, and no shape check can fail on an executor that cannot pull an image. A repository-wide search for any pipeline-status reader (glab ci, glab api .../pipelines, CI_PIPELINE_STATUS) across scripts/, deploy/, claude/ and .claude/ returns only human instructions inside deploy/gitlab-runner/README.md and the registration script. deploy/ship.sh contains no pipeline check. This is systemic pattern #1 applied to the CI surface, and it is why the outage survived 12 days, 120 pipelines, and a 38-agent analysis.

When it appeared. The blindness is NEVER-WIRED, not a regression: no pipeline-status reader has ever existed in this tree (0 hits in tracked files). The validate-ci gate itself dates to 2abdff0e 'feat(repro): CI/local runner parity — enforce the canonical runner (R6)' 2026-07-11 16:06:11 -0400 and has been document-scoped since introduction. The window in which its green was actively false began 2026-08-11T20:26:36Z (CI-01) and is 12 days old as of 2026-08-23.

Proposed fix. Add a gate whose oracle is GitLab, not the file: glab api projects/:id/pipelines?ref=master&per_page=1 and fail unless the newest pipeline for the current HEAD sha is success. Name what would have to be true for it to fail (a red or missing pipeline) and prove it can, by pointing it at HEAD today — it must go red immediately. Until that exists, validate-ci should print its own blind spot in the same output as its PASS, the way the four gates round 1 praised already do: 'validates .gitlab-ci.yml as a document; does not observe pipeline execution'.

Origin: R2·CI-02 · Files: deploy/gitlab-runner/README.md, deploy/gitlab-runner/register.sh, deploy/ship.sh, scripts/gates.py, scripts/validate_ci.py

OA-017 — 623 GitLab master pipelines, zero successes ever; 12 days of runner_system_failure that nobody read

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

The remote is git@gitlab.com:MSamy/orchestrata-ultimate-architecture.git and .gitlab-ci.yml (15,938 bytes, 11 jobs: lint, test, coverage-gate, architecture-check, vizint-compliance, vizint-provenance-e2e, build, build-image, volk_harness_nightly) does run there. It has produced 623 master pipelines from 2026-04-18T23:56:14Z to 2026-08-22T04:54:57Z. Not one of them succeeded: the API returns count 0 for ref=master&status=success, and exactly ONE successful pipeline exists in the project's entire history — 2557034680 on branch ci/ci-green, 2026-05-27. Since 2026-08-11 every job fails with failure_reason=runner_system_failure before its script runs: the incus executor cannot pull registry.gitlab.com/msamy/orchestrata-ultimate-architecture/ci:latest, "Requesting bearer token: received unexpected HTTP status: 403 Forbidden". So for 12 days no lint, test, coverage-gate or architecture-check has executed at all, and the build and coverage-gate stages sit permanently 'skipped'. This is the pipeline history the round-1 report never opened. Because nothing reads it, the failure mode silently changed from script_failure (2026-04-18 onward) to ci_quota_exceeded (2026-06-26 to 2026-07-21) to runner_system_failure (2026-08-11 onward) with no reaction.

When it appeared. NEVER GREEN — this is a never-wired condition, not a regression, for master as a whole: the oldest recorded master pipeline is 2462935674 at 2026-04-18T23:56:14Z and it failed (lint, script_failure). CI config landed 2026-04-11 (cd2b1801). The CURRENT failure mode IS a dated regression: the last script_failure sample is 2026-08-10T17:19:26Z (2748173067) and the first runner_system_failure sample is 2026-08-11T22:15:17Z (2752211843), so the registry/runner break occurred between those two timestamps — 12 days ago as of 2026-08-23. The ci_quota_exceeded era ran 2026-06-26 to 2026-07-21. Caveat: GitLab may prune very old pipeline records; the 623 recorded span the whole period from 9 days afte…

Proposed fix. Two separate repairs, in this order. (1) Fix the runner's registry credentials — the 403 on the bearer-token request means the gitlab-runner's incus executor has no valid pull credential for registry.gitlab.com/msamy/orchestrata-ultimate-architecture/ci:latest, or the image tag no longer exists; until that is fixed no evidence about the code is obtainable from CI. (2) Then attack the underlying script_failure that predates it, and do NOT declare CI wired until a master pipeline reaches status=success — the project has produced exactly one green pipeline in 126 days and it was on a throwaway branch. Add a notification so the next silent failure-mode change is not invisible for 12 days.

Origin: R2·RS-03 · Files: env, home/mohamed/workspace/orchestrata-ultimate-architecture/.gitlab-ci.yml

OA-020 — Git blame is unusable for 80.9% of the repo: a CI accident on 2026-07-27 deleted and re-added the whole tree

🔴 FATAL · debt · ⏳ unverified · evidence: measured · state: static-source

This is the mechanical cause of round 1's structural failure ('nothing is dated'). On 2026-07-27 the pre-push test suite, running from a worktree, committed two tree-deleting commits onto master: 5322ba6d "initial" (18:49:06, 4,057 files, 6,013,967 deletions) and e39f8d16 "init" (19:18:47, 4,055 files, 6,014,425 deletions). bdafa201 (19:28:19) restored the content by re-adding all 4,055 files as 6,014,425 insertions. All three are ancestors of HEAD. 3,965 of today's 4,901 tracked files (80.9%) appear in bdafa201's add-list, and in a 25-file sample, 23 files have >=91% of their lines blamed to bdafa201 — including specs/020-claude-code-harness/spec.md at 1,912 of 1,912 lines (100%). No requirement in SPEC-020, the most-cited document in round 1, can be dated by blame at all. git log -S still sees through the gap (scripts/code-review.py correctly blames back to 2026-04-19), so the repo is datable — but only with the right instrument, and round 1 used none.

When it appeared. The discontinuity is dated exactly: 2026-07-27 18:49:06 to 19:28:19 EDT, three commits, 39 minutes. Recorded rationale: PARTIAL — bdafa201's subject names the cause (the pre-push test suite hijacked the branch) but no commit, ADR or plan records the decision to leave the two destructive commits in master's history rather than rewriting them out, and none records the resulting loss of blame history.

Proposed fix. Two actions. (1) Publish this as a standing analysis rule: in this repo, date findings with git log -S <literal> and git log --diff-filter=A, NEVER with git blame or --follow, and treat any 2026-07-27 date as a null result requiring a second lookup. (2) Fix the cause — the pre-push hook must never be able to commit to master; the mutation sentinel added in 854bc6d9 the same day was the response, and it should be verified to actually block this specific sequence.

Origin: R2·H-04 · Files: architecture/current-to-target-mapping.md, claude/SESSION_SYSTEM.md, claude/hooks/error_gate/checks_structure.py, plans/execution-plan.md, plugins/orchestrata/commands/session.md, rtm/scripts/architecture_checker.py

OA-021 — GitLab CI has executed zero Python checks for 12 days — 360 consecutive runner_system_failure job runs, live-reproduced root cause

🔴 FATAL · disconnection · ⏳ unverified · evidence: measured · state: production

The CI that runs on the project's real remote is 100% red and has been since 2026-08-11T20:26:36Z. lint (ruff + black + mypy), architecture-check (architecture_checker.py --strict) and test (scripts/run_tests.py, the whole suite) have failed 360 consecutive times with GitLab failure_reason runner_system_failure — the job dies in prepare_executor, before a single script line runs. coverage-gate (--fail-under=92) has been skipped 116/116 because it needs: test, and build skipped 89 times, so the coverage floor and the artifact build have not been enforced once either. The mechanism is not a code failure: the Incus custom executor maps registry.gitlab.com/msamy/.../ci:latest to glreg:... and incus launch shells out to skopeo AS ROOT, which has no credentials for the private registry.

When it appeared. REGRESSION, dated to a 26-hour window. Last successful lint job: id 15815547498, 2026-08-10T17:54:21.534Z. First universal runner_system_failure: jobs 15842330163/164/166, 2026-08-11T20:26:36.420Z. Before that the self-hosted executor worked: 2026-08-09 and 2026-08-10 show lint and architecture-check success on essentially every pipeline (test failed with script_failure — an honest red, i.e. the checks were running). The prior era was different again: 2026-07-14 -> 2026-07-31 every job failed ci_quota_exceeded (SaaS minutes exhausted); 2026-08-02 -> 2026-08-06 jobs ran and failed on scripts; the Incus executor landed 5fcc0858 'Self-hosted CI: GitLab Runner custom executor driving In…

Proposed fix. Restore the credential and then remove the class of failure: (1) run sudo skopeo login registry.gitlab.com on the runner host with a deploy token, writing to a PERSISTENT path (--authfile /root/.config/containers/auth.json) — skopeo's root default is $XDG_RUNTIME_DIR/containers/auth.json = /run/containers/0/auth.json, which is tmpfs and dies at every boot, and this host reboots often (8 reboots recorded since 2026-08-19); (2) make prepare.sh assert the credential BEFORE launching — an explicit skopeo inspect preflight that fails with 'no registry credential for ; run sudo skopeo login' turns 360 identical opaque system failures into one actionable message; (3) add the login to a provisioning step in deploy/gitlab-runner/ so it is repo state, not undocumented machine state that…

Origin: R2·CI-01 · Files: XDG_RUNTIME_DIR/containers/auth.json, architecture_checker.py, config/containers/auth.json, deploy/gitlab-runner/incus-executor/_common.sh, deploy/gitlab-runner/incus-executor/prepare.sh, root/.config/containers/auth.json

OA-024 — SPEC-020's audit trail was specified and never built — resolving round-1 contradiction #3

🔴 FATAL · missing · ⏳ unverified · evidence: measured · state: production

Round 1 left this open in §6: 'Did ~/.claude/audit/ ever exist? This decides whether SPEC-020's audit trail is built-then-disconnected (a wiring fix) or specified-never-built (a build).' It is specified-never-built. Across the whole working tree, ~/.claude/audit/ appears in exactly 15 lines of specs/020-claude-code-harness/{spec.md,checklists/requirements.md} and in exactly ONE line of any executable-language file — a COMMENT in tests/claude/test_instruction_enforcer_hook.py:13. There is no writer, in any .py/.sh/.js/.ts, anywhere in the tree. The requirements checklist nevertheless marks REQ-020-124, REQ-020-200, REQ-020-204 and REQ-020-205 as [x] complete. The correct repair is a build, not a rewire.

When it appeared. NEVER BUILT. The spec text has been in the tree since at least bdafa201 (2026-07-27) and its content predates that; specs/020 is 100% blame-collapsed to that commit (see H-04), so an exact spec authoring date is not recoverable from blame — but it does not need to be: no writer commit exists at any point in the 3,417-commit history, which is the answer the contradiction needed. Recorded rationale for the four [x] marks against a non-existent sink: NONE.

Proposed fix. Uncheck REQ-020-124/200/204/205 in specs/020-claude-code-harness/checklists/requirements.md before anything else — a [x] against a sink that never existed is the checklist asserting a fact it never tested. Then either build the audit writer or amend SPEC-020 to drop the audit trail; do not leave a P0 spec claiming a 'never deleted' guarantee over a directory nothing creates.

Origin: R2·H-07 · Files: checklists/requirements.md, claude/audit/enforcement_log.json, claude/audit/findings/deception_log.json, nspecs/020-claude-code-harness/checklists/requirements.md, nspecs/020-claude-code-harness/spec.md, py/.sh

OA-026 — TOP-01's test-review branch is a REGRESSION pinned to one commit: e1e1a4f7 (2026-05-26) deleted --format and wired three hooks to pass it, in the same commit

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

Round 1 correctly measured that scripts/hooks/pre-commit's test-review branch exits 2 because it passes --format, which test-review.py does not define. It could not say when. Commit e1e1a4f7 (2026-05-26 12:29:48, "feat(hooks): test review + real DispatchResult in tests") rewrote test-review.py in a 512-line change that REMOVED parser.add_argument("--format", choices=["text","json"], default="text", ...) — present since 87c38cc2 on 2026-04-22 — and in the SAME commit added three hook invocations of the form python scripts/test-review.py --format text --min-severity WARNING --stdout "$FILE" 2>/dev/null, plus rewrote the module docstring to a usage example that uses the flag it had just deleted. The 2>/dev/null swallowed the argparse error, so the gate has reported 'no test issues' since the day it was wired. It has never once executed successfully. scripts/run_review_pipeline.sh:38 carries the same broken invocation.

When it appeared. REGRESSION, dated exactly: e1e1a4f7, 2026-05-26 12:29:48 -0400. Broken for 89 days. The flag existed and worked from 87c38cc2 (2026-04-22) for 34 days. Recorded rationale: NONE — the commit message documents the rewrite's new rules and the hook wiring in detail and says nothing about dropping --format; the removal appears to be collateral damage in a 512-line rewrite, and the docstring edit in the same hunk shows the author still believed the flag existed.

Proposed fix. Restore --format to test-review.py's argparse (it is still documented in the script's own docstring and used by scripts/run_review_pipeline.sh, so restoring is the smaller change than removing three call sites), and delete 2>/dev/null from every invocation — that redirect is what converted a hard argparse error into a silent pass for 89 days.

Origin: R2·H-05 · Files: kimi/hooks/post-write-review.sh, kimi/hooks/subagent-stop-review.sh, nscripts/test-review.py, ntest-review.py, scripts/run_review_pipeline.sh, scripts/test-review.py

OA-027 — The gates cache lost 20 of 23 recorded verdicts between 09:33 and 12:39 today, and error_report.py has no denominator check that could notice

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

Round 1 read .cache/gates.json at 09:33 with 24 entries recording mypy=false and plugin-drift=false. At 12:15:47 today it held 2 entries; at 12:39:35 it holds 3 — ast, prod-separation, validate-ci — all ok:true. scripts/gates.py defines 23 gates. So the battery's recorded verdict now covers 13% of the battery and records zero failures, and the two honest reds round 1 relied on are gone. scripts/gates.py::_load_cache returns {} when the file is missing or unreadable, so any deletion silently resets the record. scripts/error_report.py:203-206 then reports f"{len(entries)} gate(s); {cached} served from cache" and appends a FAIL line only for entries whose status key is non-PASS — it never compares len(entries) against the number of gates that exist. Absence of a verdict and a passing verdict are indistinguishable in its output. This compounds TOP-05: error_report cannot report red because it reads keys the producer never writes, AND cannot report incomplete because it has no denominator.

When it appeared. The mechanism is never-correct and dated to birth (see H-06): _load_cache's fail-to-empty and _save_cache's {fingerprint,ok} schema both entered at 07e5c255 on 2026-08-07 (16 days); error_report.py's status/verdict read and missing denominator both entered at 713ee031 on 2026-08-09 (14 days). The specific loss of the 24-entry cache is dated to a 3-hour window today, 2026-08-23 between 09:33 and 12:15:47, during the gap swarm. Recorded rationale: the fail-to-empty branch carries an inline comment ('a corrupt cache must never block a run') — a rationale for fail-open that is exactly systemic pattern #7; nothing records a rationale for the absent denominator.

Proposed fix. Three changes, in this order. (1) error_report.py must import the gate roster from gates.py and print N of 23 gates have a recorded verdict; M unknown, treating unknown as a loud non-pass. (2) error_report.py:201 must read ok, the key the producer actually writes. (3) _load_cache's fail-to-empty must distinguish 'missing' from 'corrupt' and say which in the run's output — silently starting from {} is how 20 verdicts vanished without a trace.

Origin: R2·H-09 · Files: cache/gates.json, error_report.py, gates.py, plans/system-analysis-2026-08-23.md, scripts/error_report.py, scripts/gates.py

OA-029 — The only CI that exists has never once been green on master: 1 success in 956 pipelines, 0 on master since 2026-04-18

🔴 FATAL · disconnection · ⏳ unverified · evidence: measured · state: production

Round 1 never read the remote's pipeline history and concluded "the enforcement layer has no automatic trigger". There IS an automatic trigger: GitLab CI has produced 956 pipelines. It has produced exactly ONE success in the project's entire history — pipeline 2557034680 on 2026-05-27 on branch ci/ci-green — and ZERO successes on master, from the first master pipeline on 2026-04-18 through the HEAD pipeline on 2026-08-22. The defect is not a missing trigger; it is a trigger that fires on every push and whose red verdict has been ignored for 126 consecutive days. A verdict nobody consumes is functionally identical to no verdict, but it is a different repair: the trigger does not need building, its output needs a consequence.

When it appeared. Never green. The red streak on master begins at the FIRST master pipeline, 2462935674 on 2026-04-18, and runs unbroken to HEAD's 2781400278 on 2026-08-22 — 126 days. This is never-wired-to-a-consequence, not a regression: there was no green state to regress from. The single lifetime success, 2026-05-27 on branch ci/ci-green (sha f9114dc9, commit "test/ci: green the test job — fix regression + guard CI-unrunnable tests"), shows the green was achieved on a dedicated branch and never landed on master.

Proposed fix. Do not build a new trigger. Make the existing one consequential: (a) make the master pipeline blocking on GitLab (protected-branch pipeline requirement), and (b) treat the 126-day red streak as the first repair, not a background condition. Until master can go green once, every claim of the form "a gate catches this" is unfalsifiable.

Origin: R2·H-01

OA-030 — The reviews/ dated write is what makes the pre-commit code-review gate a constant PASS — 12 ERRORs swallowed, measured today

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

scripts/code-review.py:1966-1971 unconditionally writes a dated report into reviews/ before honouring --stdout. That write calls output_json(..., str(dated_path)), and output_json at :1152-1153 prints "JSON report written to {output_file}" to STDOUT. scripts/hooks/pre-commit:51-52 captures that same stdout and pipes it into json.load, so the parse ALWAYS raises on line 1 and the || echo 0 fallback sets ISSUE_COUNT=0. The gate can never see a finding. Round 1 (TOP-01) reported the fail-open as inferred and did not identify the cause; the cause is the reviews/ sink itself. I reproduced the exact production pipeline against a real production source file: stdout line 1 was the banner, json.load raised, ISSUE_COUNT=0, and the report that same run wrote recorded total_issues=12 with summary_by_severity {'ERROR': 12, 'WARNING': 6, 'INFO': 12}. Twelve ERROR-severity findings on a file that is currently failing the mypy gate would pass the pre-commit review branch today.

When it appeared. NEVER WIRED, not a regression. The stdout banner has existed since 2026-04-19 (81973ac8 "code review"), the only commit matching git log -S 'Always write a dated report to reviews/' -- scripts/code-review.py. The --stdout flag was added 2026-05-26 (03422f78 "feat(hooks): add --stdout flag to code-review.py, update hooks to use it"), but git cat-file -e 03422f78:scripts/hooks/pre-commit returns ABSENT — the live hook did not exist then. git log --diff-filter=A -- scripts/hooks/pre-commit returns exactly one commit: 854bc6d9 2026-07-27, and git show 854bc6d9:scripts/hooks/pre-commit | grep -n code-review shows the identical parse already at line 35 of its first version. The gate has b…

Proposed fix. Send the code-review.py:1153 banner to stderr (the sibling banner at :1990 already uses file=sys.stderr — this one was simply missed), OR make the dated reviews/ write conditional on not args.stdout. Then add a negative-corpus assertion to the hook: feed it a file with a known ERROR and require a non-zero ISSUE_COUNT, so the gate is required to demonstrate it CAN fail. Do not fix the hook's parse alone — the producer's contract is the defect.

Origin: R2·RS-01 · Files: R/scripts/code-review.py, R/src/orchestrata_ultimate/postman/governance.py, code-review.py, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/code-review.py, home/mohamed/workspace/orchestrata-ultimate-architecture/src/orchestrata_ultimate/postman/governance.py, reviews/code-review-2026-08-23-123443.json

OA-032 — The three CI jobs carrying all remaining enforcement abort in the runner in 11 seconds — 0 gate scripts execute on the remote today

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

.gitlab-ci.yml — the only CI definition the remote can run — invokes exactly two gate scripts: scripts/architecture_checker.py and scripts/run_tests.py. Both live in jobs (architecture-check, test) that currently fail with failure_reason=runner_system_failure after ~11 seconds, alongside lint. That is not a code failure; it is the job dying before its script runs. Across the 12 most recent pipelines the signature is identical and uniform: 3 runner_system_failure, 2 skipped, 2 success. The two jobs that DO pass (vizint-compliance, vizint-provenance-e2e) run on the same runner (orchestrata-incus, id 54962152), so this is job-specific, not a runner outage. Net result: the number of enforcement scripts that actually execute on the project's only remote is zero, and the pipeline still reports per-job statuses that a reader could mistake for having been evaluated.

When it appeared. A REGRESSION with two dated steps. (1) 2026-07-19 through 2026-07-26: all jobs failed with ci_quota_exceeded — GitLab.com shared-runner minutes exhausted; the self-hosted orchestrata-incus runner was the response. (2) Between 2026-08-03 (script_failure, jobs executing) and 2026-08-19 (runner_system_failure, jobs not executing) the three jobs stopped running at all. The exact commit is not identifiable from the repo because the failure is in the runner's Incus executor environment, not in tracked CI YAML — .gitlab-ci.yml's last change is 3d0b6774 on 2026-08-16, which is inside that window and is the prime suspect (a subnet sweep touching CI comments). No commit records a rationale for accept…

Proposed fix. Fix the Incus executor for the three aborting jobs before touching anything else in the enforcement layer — while they abort, adding gates to CI adds nothing. Then make runner_system_failure a distinct, loud state in whatever reads pipeline status: an aborted job is 'not evaluated', which must never present the same way as 'evaluated and passed'.

Origin: R2·H-02 · Files: deploy/gitlab-runner/incus-executor/prepare.sh, deploy/gitlab-runner/incus-executor/run.sh, nscripts/architecture_checker.py, nscripts/run_tests.py, scripts/architecture_checker.py, scripts/run_tests.py

Enforcement & Gates

OA-002 — The git pre-commit hook reports 0 issues on a file with 4 ERROR findings — code-review.py prefixes its JSON with a stdout banner and the hook falls back to || echo 0

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: `` · corroborated ×3

scripts/hooks/pre-commit — the live hook, since core.hooksPath=scripts/hooks — parses code-review.py's stdout as JSON, the parse always fails because output_json() unconditionally prints "JSON report written to " to stdout before the JSON, and the 2>/dev/null || echo 0 fallback turns every failure into ISSUE_COUNT=0, so the commit is never blocked.

Proposed fix. Fix the generator, not the caller: send the "JSON report written to" line at code-review.py:1153 to sys.stderr, matching line 1991. Then fix the caller too — scripts/hooks/pre-commit must use the script's exit code (already 1 on ERRORs) instead of re-deriving a count, must not swallow stderr with 2>/dev/null, and must not use || echo 0, which converts every failure of the gate into a pass. Bare python (=/usr/bin/python, the system interpreter) should be uv run python per platform convention.

Origin: R1·GATES-FG-002, R1·GATES-BYPASS-001, R1·CPLX-006 · Files: code-review.py, home/mohamed/workspace/orchestrata-ultimate-architecture/code-review.py, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/code-review.py, reviews/code-review-2026-08-23-090541.json, reviews/code-review-2026-08-23-090959.json, scripts/code-review.py

OA-004 — 25 of 57 live hook registrations — the entire .claude/settings.json project surface — did not fire in this subagent session

🔴 FATAL · disconnection · ✅ confirmed · evidence: measured · state: `` · corroborated ×2

Every hook registered in .claude/settings.json failed to execute for this session's tool calls, while user-scope plugin hooks executed normally on the same calls, so the project enforcement layer (single-gate-entrypoint, no-xdist, force-ast-toolkit, force-test-observation, no-unbounded-wait, force-trace-intel, proportionate-test-scope, no-doubles-py, no-banned-deps, require-design-before-build, workflow-default-sonnet, typecheck-on-write and the five Stop guards) is absent exactly in the sessions that do the building.

Proposed fix. Do not rely on .claude/settings.json registrations to constrain delegated agents. Either (a) move the enforcement guards onto a surface subagents load — the plugin declaration, which measurably fires here — or (b) make each project hook resolve its own repo root instead of cd "$CLAUDE_PROJECT_DIR" &&, and make an unresolvable root DENY rather than short-circuit to allow. Before either, instrument a main session the same way to establish whether the gap is subagent-specific or total; the current 'live PreToolUse guard' claim in plans/claude-surface-promotion-plan.md:157-159 ('live IMMEDIATELY in every session whose cwd is this repo') is false as written.

Origin: R1·HOOKREG-001, R1·HOOKREG-005 · Files: PREFIX/scripts/patch_settings.py, PREFIX/settings.hooks.json, PREFIX/settings.json, STAGE/claude/scripts/patch_settings.py, STAGE/claude/settings.hooks.json, claude/README.md

OA-007 — The architecture gate cannot fail: no local runner passes --strict, so architecture_checker.py always exits 0

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: `` · corroborated ×2

scripts/architecture_checker.py returns 0 for any number of layer, DI-container, direct-driver and graph-seam violations unless --strict is passed, and four of the five runners that invoke it — including scripts/gates.py, the guard-enforced battery — omit the flag.

Proposed fix. Add --strict to gates.py:66, scripts/health_check.py:79 and .pre-commit-config.yaml:38, or invert the default so violations exit 1 and a --report-only flag opts out. The source comment at architecture_checker.py:681 ("In non-strict mode we exit 0 so the gate passes while violations are documented") is the defect, not a note about it — a gate whose default is 'document, do not fail' is not a gate. gates.py's own mypy entry already states the correct principle ("THE SAME COMMAND CI's lint job runs"); the architecture entry violates it, since CI runs src/ --strict and the battery runs src/orchestrata_ultimate non-strict — a different scope AND a different verdict rule.

Origin: R1·GATES-FG-001, R2·ARCH-01 · Files: architecture_checker.py, cache/gates.json, gates.py, github/workflows/ci.yml, home/mohamed/workspace/orchestrata-ultimate-architecture/.pre-commit-config.yaml, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/architecture_checker.py

OA-009 — The pre-commit test-review gate has never executed — its invocation is an argparse error

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: `` · corroborated ×2

scripts/hooks/pre-commit invokes scripts/test-review.py with a --format flag that test-review.py does not define, so the command exits 2 before running any check, stderr is discarded, and the hook records zero issues for every staged test file.

Proposed fix. Either add a real --format json emitter to test-review.py or change the hook to consume its exit code (1 = ERROR found) instead of parsing JSON. Remove 2>/dev/null and || echo 0 from both branches so an unparseable or failing gate blocks the commit.

Origin: R1·GATES-BYPASS-002, R1·PURITY-002 · Files: home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/test-review.py, ntest-review.py, scripts/code-review.py, scripts/test-review.py, test-review.py, tests/core/test_gate_waivers.py

OA-010 — gates.py --only <unknown-name> prints ALL GATES PASS and exits 0 having run zero gates

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: `` · corroborated ×2

main() builds selected by filtering GATES against --only without validating the names, so a typo, a renamed gate, or a removed gate name yields an empty selection, an empty failure list, the literal line '[gates] ALL GATES PASS', and exit code 0.

Proposed fix. Reject unknown --only names with exit 2 and a list of valid gates before any work. The output string 'ALL GATES PASS' is quoted as evidence of a green battery in docs/development-and-testing.md:406 and in commit messages, and a zero-gate run produces a byte-identical string — the reader cannot tell them apart.

Origin: R1·GATES-FG-004, R1·GATES-BYPASS-003 · Files: cache/gates.json, gates.py, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/gates.py, scripts/gates.py

Runtime & Deployment

OA-001 — 7 of 8 prod units execute the DEV checkout's interpreter at every start

🔴 FATAL · drift · ✅ confirmed · evidence: measured · state: `` · corroborated ×5

Every orchestrata/orchgraph unit except orchestrata-history-mining runs /home/mohamed/.local/bin/orchestrata-kg-ready as a non-optional ExecStartPre, and that script's shebang binds /home/mohamed/workspace/orchestrata-ultimate-architecture/.venv/bin/python, so the production services cannot start without executing code out of the live development git checkout.

Proposed fix. Move the readiness probe into the prod tree (e.g. prod/orchestrata-ultimate/deploy/orchestrata-kg-ready) and change all 7 ExecStartPre lines in deploy/systemd/*.service to /home/mohamed/prod/orchestrata-ultimate/.venv/bin/python /home/mohamed/prod/orchestrata-ultimate/deploy/orchestrata-kg-ready. Fix the unit templates in deploy/systemd/ and plugins/orchestrata/systemd/, not the installed copies — deploy/systemd/install.sh re-installs from the repo and would revert a hand-patch.

Origin: R1·RUNTIME-001, R1·RUNTIME-ENVSEP-001, R1·RUNTIME-DEPLOY-001, R1·RUNTIME-DEPLOY-002, R1·RUNTIME-003 · Files: check_prod_tree_separation.py, deploy/install-claude-config.sh, deploy/ship.sh, deploy/systemd/orchestrata-kg-ready.py, home/mohamed/.config/systemd/user/orchestrata-ast-live-sync.service, home/mohamed/.config/systemd/user/orchestrata-bot.service

OA-006 — Deployed turn-capture hook defaults REDIS_HOST to localhost — RUL-003 violated in production

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: `` · corroborated ×2

claude/tools/claude_turn_capture.py:101-102 supplies literal fallbacks "localhost" and "6379" for REDIS_HOST/REDIS_PORT, the file is deployed byte-identical to ~/.claude/tools/claude_turn_capture.py and registered as a live hook in every project, and the process is fail-open with sys.exit(0) so the fallback produces silent turn-capture loss instead of a loud configuration error.

Proposed fix. Route _build_redis_client through core.redis_factory.resolve_redis_host/resolve_redis_port (both verified to raise under env -i), or read the keys with a one-arg get and raise naming the key. Then close the two detector holes (INFRA-CONTRACTS-002 and -003) in the same change, because fixing only this file leaves the class of defect undetectable.

Origin: R1·INFRA-CONTRACTS-001, R1·TESTS-ORACLE-002 · Files: CLAUDE_PROJECT_DIR/.env, HOME/.claude/tools/claude_turn_capture.py, HOME/.env, claude/hooks/ast_sync_hook.py, claude/settings.hooks.json, claude/tools/claude_turn_capture.py

OA-023 — SPEC-020's audit trail has zero writers and zero sinks while its checklist is 240/240 checked

🔴 FATAL · missing · ✅ confirmed · evidence: measured · state: ``

Every hook SPEC-020 names as an audit writer is deployed to ~/.claude/hooks/ and registered on none of the six live registration surfaces, and neither mandated sink — ~/.claude/audit/ nor ~/.claude/logs/file_operations.log — exists, so nothing the harness does is recorded.

Proposed fix. Two separable defects, both to be fixed rather than documented away. (1) Wire the four audit writers into claude/settings.hooks.json and plugins/orchestrata/hooks/hooks.json by regenerating from the generator (gen_plugin.py), not by hand-editing the deployed cache — posttool_auditor on PostToolUse(.*), log_operation on PreToolUse(Write|Edit|Bash), stop_auditor on Stop, stop_auditor_subagent on SubagentStop — then verify by asserting ~/.claude/audit/sessions/ is non-empty after one turn. (2) Either add the file_operations.log append to intercept_bash/intercept_write/intercept_edit, or amend spec.md:793 and :806 which currently assert a behaviour those hooks have never had. Separately, specs/020-claude-code-harness/checklists/requirements.md at 240/240 checked is an unverified ass…

Origin: R1·OBS-RUNTIME-002 · Files: __init__.py, block_except_pass.py, claude/plugins/cache/orchestrata/orchestrata/1.3.0/hooks/hooks.json, claude/settings.hooks.json, claude/settings.json, claude/settings.local.json

OA-036 — scripts/error_report.py can never report a failed gate — key-name mismatch with the cache it reads

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: ``

scripts/error_report.py::gates classifies each gate by body.get("status") or body.get("verdict"), keys that scripts/gates.py::_save_cache never writes, so the tool banner-titled "read this before reporting status" printed "No red finding in the artifacts read" and exited 0 while the cache it had just read recorded two gates as failed.

Proposed fix. Fix the reader at the layer the defect manifests: make scripts/error_report.py::gates read the ok boolean that scripts/gates.py::_save_cache actually writes, and make build_report return non-zero when any gate has ok=false. Add a test that writes a cache with one ok=false entry and asserts the report contains a FAIL line and a non-zero exit — an oracle that can fail. The cached/reused display path is likewise dead against this schema and must either be wired to a key gates.py emits or removed.

Origin: R1·OBS-RUNTIME-001 · Files: cache/gates.json, home/mohamed/workspace/orchestrata-ultimate-architecture/.cache/gates.json, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/error_report.py, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/gates.py, reports/run-tests-latest.json, scripts/error_report.py

Docs & Knowledge

OA-005 — Deleted generator still declared by a tracked artifact; the loss-detector reports OK

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: `` · corroborated ×2

reports/kg-dialect-failures-2026-07-26.md names scripts/kg_dialect_preflight.py as its generator, that script was deleted on 2026-07-27 in commit e73df607, and the generated-artifacts gate prints "generator provenance satisfied" because its header-discovery regex cannot cross a backtick and its scan never covers reports/.

Proposed fix. In scripts/check_generated_artifacts.py, add optional opening-quote tolerance to _HEADER_GENERATOR_RE, and extend both check_generator_headers and scan_generator_headers defaults from ("tests","src","docs") to include "reports", "plans", "claude", ".claude", "scripts", "specs", "infra", "plugins", "deploy". Then decide reports/kg-dialect-failures-2026-07-26.md: restore scripts/kg_dialect_preflight.py from e73df607~1, or retire the artifact — retirement needs the user's explicit approval per the gate's own remedy language. Add a regression test in tests/scripts/test_check_generated_artifacts.py that fixtures a backticked "Generated by scripts/gone.py" header under reports/ and asserts a [LOSS] violation.

Origin: R1·DOCS-GENROT-001, R2·AF-02 · Files: docs/LEVEL0.md, generate_pytest.py, home/mohamed/workspace/orchestrata-ultimate-architecture/reports/kg-dialect-failures-2026-07-26.md, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/check_generated_artifacts.py, nreports/kg-dialect-failures-2026-07-26.md, plans/rtm.md

OA-016 — 36 gRPC claims in the always-loaded doc tier describe a transport the code REJECTS at runtime

🔴 FATAL · contradiction · ✅ confirmed · evidence: measured · state: ``

AGENTS.md, CLAUDE.md, docs/LEVEL0.md and docs/CODEBASE_MAP.md state 36 times that the kernel speaks gRPC on port 50053, while cxp_transport() raises ValueError on CXP_TRANSPORT=grpc, all three env profiles pin CXP_TRANSPORT=cxpt, create_cxp_server has no gRPC branch, grpcio/grpcio-tools/grpc are listed in .claude/banned-libraries.txt as RETIRED 2026-08-07, and import grpc fails in the project venv.

Proposed fix. Fix the GENERATOR first: replace 'gRPC' with 'cxpt' at scripts/gen_level0.py:165 and :206 and at scripts/gen_codebase_map.py wherever it emits the kernel row, then regenerate. Hand-edit the 27 remaining mentions in AGENTS.md and CLAUDE.md (they have no generator). Then add 'grpc' presented as the CURRENT kernel transport to doc_lint's _STALE_PATTERNS — this is exactly the retired-infrastructure class check 1 exists for, and it caught none of the 36 because the pattern list stops at 10.222.9.x / swiplserver / MQI / gatekeeper-neo4j.

Origin: R1·DOCS-TRUTH-003 · Files: docs/CODEBASE_MAP.md, docs/LEVEL0.md, docs/kernel-is-required.md, env/dev.env, gen_level0.py, home/mohamed/workspace/orchestrata-ultimate-architecture/AGENTS.md

OA-018 — AGENTS.md names a different, 4-month-stale git repository as the edit target

🔴 FATAL · contradiction · ✅ confirmed · evidence: measured · state: ``

AGENTS.md:285 tells a fresh agent the work-in-progress target is /home/mohamed/workspace/orchestrata-ultimate/src/orchestrata_ultimate/, which is a separate git repository with a different remote, a HEAD from 2026-04-11 and 41 Python modules, not this checkout's 868.

Proposed fix. Change AGENTS.md:285 to the repo-relative 'src/orchestrata_ultimate/' as CLAUDE.md:41 already has it. AGENTS.md:13, :284, :310, :387 and :1023 correctly name the frozen SOURCE monorepo at /home/mohamed/workspace/orchestrata/packages/ — only :285 points outward. Add a doc_lint check that every absolute /home/mohamed path in a doc resolves inside this repo or into the declared frozen source.

Origin: R1·DOCS-ONBOARD-001 · Files: home/mohamed/workspace/orchestrata-ultimate-architecture/AGENTS.md

OA-019 — All 10 documented session subcommands fail on the CLI a fresh agent resolves, including the startup-protocol entry point

🔴 FATAL · contradiction · ✅ confirmed · evidence: measured · state: ``

The session binary on a fresh agent's PATH is /home/mohamed/.local/bin/session, whose argparse dispatch accepts none of the 10 subcommands CLAUDE.md and AGENTS.md document; every one exits 2, including session overview, which AGENTS.md:76-100 makes the first command of the Automatic Startup Protocol.

Proposed fix. Pick one CLI as the project's session entry point and make every doc name it explicitly. Either write .venv/bin/session <verb> throughout CLAUDE.md:56-62 and AGENTS.md:221-280 (the .claude/hooks/session-overview.sh hook already does exactly this at line 22), or add the click verbs to ~/.claude/tools/session_cli.py so the PATH-resolved binary honours the documented surface. A verb-parity test between the two entry points would have caught the divergence.

Origin: R1·DOCS-ONBOARD-002 · Files: home/mohamed/workspace/orchestrata-ultimate-architecture/AGENTS.md, home/mohamed/workspace/orchestrata-ultimate-architecture/CLAUDE.md

Knowledge Graphs

OA-008 — The live production kernel and gateway resolve their semantic-retrieval corpus to 61 stale agent-worktree files, not the source tree

🔴 FATAL · drift · ✅ confirmed · evidence: measured · state: production · corroborated ×2

~/prod/orchestrata-ultimate/.env:58-59 sets MEMGRAPH_CHUNK_LABEL=SemanticChunk and MEMGRAPH_VECTOR_INDEX_NAME=semantic_chunk_embedding_idx. orchestrata-kernel.service:27 loads that file as EnvironmentFile=, and env/prod.env (layered at :32) does not override either key. SemanticGraphConfig.from_env() (config.py:108) therefore returns chunk_label='SemanticChunk' in production, and knowledge_graph/semantic_bridge.py:73-74 issues MATCH (c:{chunk_label}) WHERE toLower(c.content) CONTAINS $term against it — this is the retrieval leg of render_semantic_context (SPEC-107 REQ-107-015) and of the search_code_semantic volk tool (tools/context_tools.py:621,653,676). Measured live: all 1,418 :SemanticChunk nodes come from 61 distinct sources, every one under .claude/; 1,274 of them (89.8%) from .claude/worktrees/agent-a578908f534234feb/. The corpus contains agent prompt markdown, .claude/settings.json, .claude/settings.local.json and three SKILL.md files. It contains zero files from src/, docs/, specs/ or any other source root. The current 7,334-chunk CodestralChunk index — which IS byte-current — is never queried by this path.

When it appeared. NEVER CORRECTLY WIRED, with a compounding regression. config.py's default became CodestralChunk on 2026-07-08 (git log -S 'chunk_label: str = "CodestralChunk"' -- src/.../semantic_graph/config.py -> fb9d233c 2026-07-08). .env.example added the SemanticChunk/semantic_chunk_embedding_idx override three days later, 2026-07-11 (git log -S 'MEMGRAPH_VECTOR_INDEX_NAME' -- .env.example -> c51076d6, 'env contract — complete .env.example + validate_env preflight (R2)'), and the override has never matched the ingest label since. c3e37a54 (2026-08-09, 'Name the vector space after whatever filled it') made the label backend-derived and did not update .env.example. .env itself is untra…

Proposed fix. Delete MEMGRAPH_CHUNK_LABEL and MEMGRAPH_VECTOR_INDEX_NAME from .env, ~/prod/orchestrata-ultimate/.env and .env.example, and make SemanticGraphConfig.from_env() derive both from embedder_factory.chunk_label()/vector_index_name() so there is ONE resolution path instead of two. Add a startup assertion in the adapter that the configured index's declared dimension equals embed_dimension() and that the configured label is the one the selected backend writes — refuse to serve retrieval otherwise. Then re-run the six probe queries against the kernel path and require non-zero hits on a symbol added in the last 48h.

Origin: R2·GRAPH-01, R2·GRAPH-13 · Files: claude/settings.json, claude/settings.local.json, config.py, embedder_factory.py, env/prod.env, home/mohamed/.config/systemd/user/orchestrata-kernel.service

OA-012 — 1,236 legacy requirement ids live in the production KG after the commit that declared their return impossible

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

Commit fb167c13 (2026-08-19) 'refactor(specs): eliminate legacy story ids corpus-wide and make their return impossible' migrated 47,715 occurrences across 388 files and installed three enforcement layers (a grammar that rejects the shape, a counter, and a corpus-guard test that 'scans every file'). All three are file scanners. The production operational KG — the storage tier that context injection actually reads — still serves 1,236 requirement ids in the legacy REQ-NNN-USn-MMM form. Disk carries 0. check_req_format.py's DEFAULT_ROOTS is ('specs', 'src/orchestrata_ultimate', 'tests') and the file contains 0 occurrences of graph/cypher/memgraph/bolt/orchkg.

When it appeared. REGRESSION dated exactly: the guarantee was made on 2026-08-19 17:42:05 -0400 in fb167c13 and was false for the graph at the moment it was made. Measured 2026-08-23 — 4 days later, still 1,236. The graph's copies predate the migration; the last spec write into orchkg is before 2026-07-23 (see GS-04).

Proposed fix. Add a graph arm to check_req_format.py (or a new gate) that runs the same grammar over :RequirementItem.req_tag in orchkg and fails on any legacy hit, and sweep the 1,236 existing nodes. Until then no 'legacy ids are gone' claim is true of the system, only of its files.

Origin: R2·GS-03 · Files: check_req_format.py, scripts/check_req_format.py, scripts/migrate_legacy_story_ids.py, tmp/.../legacy_ids_in_graph.py

OA-015 — 23.6% of the production operational KG is unreachable from any :Project root — regression from a measured 0 on 2026-07-26, gate exits 1 and nothing runs it

🔴 FATAL · disconnection · ✅ confirmed · evidence: measured · state: production

The session-254 ruling states that every node in the operational KG must be reachable from a root :Project node. In production right now 67,665 of 286,576 nodes (23.6%) are not. The checker built to enforce it, scripts/check_kg_connectivity.py, works correctly and exits 1 — it is registered in scripts/health_check.py:644 as a REQUIRED (not advisory) check, and scripts/health_check.py itself is invoked by no CI job, no systemd unit, no git hook, no ship stage and no gate. It is not one of the 24 entries in scripts/gates.py::GATES. The invariant has therefore been false and unobserved for four weeks.

When it appeared. REGRESSION, precisely bracketed. Commit c33e6bdd (2026-07-26 05:16 'Root-connectivity: writer fixes + BFS gate wired into health_check') records in its own message: 'Live gate: 66,160/66,160 reachable, UNREACHABLE=0, exit 0.' The context.json backlog entry recording growth to 8,447 unreachable is timestamped 2026-07-27T14:57:18 — one day later. Today 2026-08-23 12:10 it is 67,665, an 8x growth on the last recorded number. git log -S 'compute_connectivity' -- scripts/health_check.py returns nothing after c33e6bdd, so the wiring into health_check was never removed — health_check itself simply has no runner.

Proposed fix. Give health_check.py an automatic trigger, or lift check_kg_connectivity.py into scripts/gates.py::GATES as a live-infra gate. Then repair the data: the three subtrees without a :Project root are KG-04 and KG-05; deleting those two stale subtrees removes 1796 of 1796 orphan Modules, 13,344 of 13,344 orphan Methods, 3,485 of 3,485 orphan Classes, 4,202 of 4,202 orphan Functions and 37,489 of 37,489 orphan Parameters — i.e. the whole code-layer orphan set — leaving only the 5,551 conversation-layer orphans. Pin the invocation to the venv interpreter, not bare python.

Origin: R2·KG-01 · Files: deploy/ship.sh, env/prod.env, github/workflows/ci.yml, health_check.py, home/mohamed/workspace/orchestrata-ultimate-architecture/context.md, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/check_kg_connectivity.py

OA-035 — Zero TRACES_TO edges in the production KG: two incompatible node-id schemes

🔴 FATAL · disconnection · ⏳ unverified · evidence: measured · state: production

The operational knowledge graph orchkg contains 0 TRACES_TO relationships against 8,026 @traces-decorated entities in src/ citing 3,109 distinct requirement ids. The trace writer builds entity ids as {project}:{rel_path}::{Class}.{method}; the writer that actually populates the live graph (GraphSyncer, via canonical_schema.project_qualified_id) builds them as {project}:{dotted.qualified_name}. Zero of the 47,003 live Class/Function/Method nodes contain '::', so the MERGE in _write_trace_relationships can never match a node. Four production readers query TRACES_TO and get nothing back: kernel/pipeline_kg.py:37 (KgRelevanceRetriever), context_injector.py:1303, requirement_resolution.py:161, context_pack/relevance.py:176.

When it appeared. NEVER-WIRED against the live writer, not a regression. The '::' entity_id was introduced 2026-07-12 in 9cc64537 'fix(kg): project-scoped AST + spec-tier identity — multi-project wave W2' (git log -S 'entity_id = f"{pid}:{rel_path}::'). The canonical dotted project_qualified_id was introduced 2026-07-22 in f51b5d67 'fix(tests+kg): eliminate parallel-collision failure classes across the suite' (git log -S 'def project_qualified_id'). The two schemes have coexisted for 32 days. I could not establish whether TRACES_TO edges existed before 2026-07-12: the graph carries no history and this file's git history begins 2026-06-18 (b46336d6).

Proposed fix. Make _accumulate_trace_info and _stage_code.py call canonical_schema.project_qualified_id instead of hand-building '{pid}:{rel}::{name}'. Then add a gate that asserts TRACES_TO count > 0 and that a sample of @traces citations resolves end-to-end in the graph — the current sync reports 'relationships_created += 0' as success, which is measurement trap #6 (success asserted against the wrong oracle).

Origin: R2·GS-01 · Files: context_injector.py, context_pack/relevance.py, kernel/pipeline_kg.py, requirement_resolution.py, scripts/graph_query.py, src/orchestrata_ultimate/kernel/pipeline_kg.py

Supply Chain & Payloads

OA-013 — 11 real GIL-flip test failures were reclassified as flakes and superseded by solo passes; CI records them in an artifact nothing reads

🔴 FATAL · false-green · ⏳ unverified · evidence: measured · state: production

scripts/run_tests.py re-runs every batch-failed module alone and lets the solo pass OVERWRITE the batch failure, logging the discarded failure to .flake_recoveries.ndjson as a 'load/order flake'. A GIL re-enablement is not a flake: it is a deterministic, irreversible, process-wide state change caused by a sibling module in the same batch. The log holds 11 such discarded failures across 7 distinct days (2026-08-11 to 2026-08-21 20:23, the most recent run) over three victim modules. .gitlab-ci.yml:224 collects .flake_recoveries.ndjson as a job ARTIFACT only — no job reads it, no threshold, no failure condition — so every one of these runs reported green.

When it appeared. FIRST OBSERVED 2026-08-11T20:55:30, MOST RECENT 2026-08-21T20:23:28 (2 days before this analysis), 7 distinct days. Solo-recovery itself was introduced with the rationale dated 2026-07-10 in the run_tests.py docstring. This is a NEVER-WIRED gap, not a regression: solo-recovery was designed for genuine order flakes and no supersede-exclusion for hard-state failures was ever specified. The .flake_recoveries.ndjson file starts 2026-07-10T04:14:36, so the log predates the GIL records by a month — the GIL class appeared 2026-08-11.

Proposed fix. Make solo-recovery refuse to supersede a failure whose text names an irreversible process-state condition (start with 'The GIL is enabled'): those are order-DEPENDENT, not order-FLAKY, and a passing solo run proves nothing about the batch. Then add a CI job that reads .flake_recoveries.ndjson and fails the pipeline on any GIL record — the artifact is already collected; only the consumer is missing.

Origin: R2·GS-01 · Files: home/mohamed/workspace/orchestrata-ultimate-architecture/.gitlab-ci.yml, home/mohamed/workspace/orchestrata-ultimate-architecture/scripts/run_tests.py, run_tests.py, scripts/run_tests.py, tests/scripts/test_code_intel.py, tests/tools/test_codebase_query_tools.py

OA-025 — SentenceTransformerEmbedder._load_model() flips the GIL process-wide and irreversibly; 6,535 of 33,259 collected tests run after it

🔴 FATAL · risk · ⏳ unverified · evidence: measured · state: production

src/orchestrata_ultimate/semantic_graph/embedders.py:375 defers from sentence_transformers import SentenceTransformer into _load_model(). That import loads tokenizers.tokenizers, which has not declared it can run without the GIL, so CPython re-enables the GIL for the whole process and never turns it back off. The flip happens BEFORE the model can fail — measured with a nonexistent model name, the GIL was on after RepositoryNotFoundError. tests/semantic_graph/test_embedders.py's _load_qwen_model() calls it (CUDA is available on this machine and the 1.2 GB model is cached), and that module sits at collection positions 26722-26743 of 33259, leaving 6,535 tests (19.6%) to execute in a GIL-ENABLED interpreter in the same process. Reproduced end-to-end in the suite's own default order.

When it appeared. The collision became possible 2026-07-18 (8a471f56 'prolog codeintel: janus is THE query transport — fail-fast, no fallback' added both _assert_free_threaded and test_assert_free_threaded_injection_seam), 36 days ago. The trigger side is older: 5f0d3edb 2026-07-08 added SentenceTransformerEmbedder, its deferred sentence_transformers import and _load_qwen_model in one commit; tokenizers and triton entered uv.lock the same day (51c8e3a2 2026-07-08). NEVER WIRED, not a regression — no commit ever mediated between the two. Env profiles made local the dev/test default later still (aac1b552 2026-08-09), but the test fixtures hard-construct SentenceTransformerEmbedder and never read the profile, s…

Proposed fix. Move the sentence-transformers import out of the shared test process: run the local-embedder tests in a dedicated pytest subprocess (their own batch, scheduled last), or gate _load_model() behind an explicit opt-in that the batched runner never sets. Do NOT 'fix' it by monkeypatching or skipping — both are banned here. Long term the only durable fix is upstream: tokenizers must declare Py_MOD_GIL_NOT_USED, or be vendored free-threaded the way tree-sitter and janus already were.

Origin: R2·GS-02 · Files: docs/free-threaded-prolog.md, home/mohamed/workspace/orchestrata-ultimate-architecture/src/orchestrata_ultimate/semantic_graph/embedders.py, home/mohamed/workspace/orchestrata-ultimate-architecture/src/orchestrata_ultimate/tools/codebase_tools.py, home/mohamed/workspace/orchestrata-ultimate-architecture/tests/semantic_graph/test_embedders.py, home/mohamed/workspace/orchestrata-ultimate-architecture/tests/tools/test_codebase_tools.py, nsrc/orchestrata_ultimate/tools/codebase_tools.py

OA-033 — The un-rotated DEEPSEEK_API_KEY in pushed git history is the same key production uses today

🔴 FATAL · risk · ✅ confirmed · evidence: measured · state: production

.env.pre-orchgraph-cutover.1783689323 survives in three commits reachable from origin/master (pushed to git@gitlab.com:MSamy/orchestrata-ultimate-architecture.git) carrying four non-empty credential values. One of them, DEEPSEEK_API_KEY (len=35, sha256[:12]=de1581d0d6e6), is byte-identical to the value currently in .env (dev, mode 600), ~/.env (mode 600) and ~/prod/orchestrata-ultimate/.env (mode 644) — the file seven running production units load via EnvironmentFile=. GITLAB_TOKEN (64->61 chars, sha 53a7f1e7a837 -> 07811e427394) and OPENROUTER_API_KEY (sha 5a08aa1697e2 -> 58f2a82c19b5) WERE rotated; NEO4J_PASSWORD no longer appears in any live env file. So 1 of 4 leaked credentials remains live and unrotated. I did not and will not test the credential against DeepSeek; the identity claim is a sha256 comparison of the historical blob against the live production env file.

When it appeared. Committed 2026-07-10 (a8189e51), re-committed 2026-07-27 (e39f8d16 init, bdafa201), removed from the working tree 2026-08-12 (d08aaf60) whose own message states: "removing it from history and rotating those credentials are separate decisions, not closed by this commit." Neither decision has been taken in the 11 days since. NOT a regression — an explicitly deferred remediation that was never completed.

Proposed fix. Rotate DEEPSEEK_API_KEY now — it is the only one of the four still live. Then either purge the blob from history (git filter-repo + force-push, coordinated) or accept it in writing and record the acceptance. Add a history-scanning gate (see SEC-06); check_secret_leaks.py structurally cannot see this.

Origin: R2·SEC-01 · Files: env, home/mohamed/.env, home/mohamed/prod/orchestrata-ultimate/.env, home/mohamed/workspace/orchestrata-ultimate-architecture/.env, prod/orchestrata-ultimate/.env

OA-034 — Two live credentials sit in plaintext in every one of the 14 retained backup snapshots (8.86 GiB, unencrypted, inside the DEV checkout)

🔴 FATAL · risk · ⏳ unverified · evidence: measured · state: production

The orchkg snapshot inside every retained backup run contains the live GITLAB_TOKEN and the live GDRIVE_CLIENT_SECRET in plaintext. GDRIVE_CLIENT_SECRET in the 2026-08-23 snapshot is byte-identical to the value in ~/.env (both len=35, sha256 prefix 0ff705e9158fb842 on both sides) and appears 6 times. The GITLAB_TOKEN string captured from the snapshot (len=48) is a proven substring of the live ~/.env GITLAB_TOKEN (len=61) — shell case-match returned 'snapshot token IS a substring of the live GITLAB_TOKEN in ~/.env'. A retired NEO4J_PASSWORD (len=10) is also present; the live ~/.env value for that key is now empty. Provenance is exact: the bytes sit inside a conversation-turn node in the orchkg database (project orchestrata-ultimate, turn id e7e858d8-c38d-4f37-ba54-71dc45353984, role assistant, source claude-code, timestamp 2026-07-18T17:47:45.566Z) whose text quoted the PAT verbatim out of a Todoist task description — and which, in the same message, warned that 'a PAT sitting in a Todoist task description is readable by anything with Todoist access'. The ingestion path performs no redaction: grep -i 'redact|scrub|sanitiz|secret|glpat|mask' over claude/tools/claude_turn_capture.py returns zero hits. Every one of the 14 retained runs (2026-08-10 through 2026-08-23) contains a glpat- match; the archive is 0640 files under 0755 directories, unencrypted, gitignored at .gitignore:277, and single-copy.

When it appeared. The credential entered the conversation corpus 2026-07-18T17:47:45.566Z (timestamp carried on the turn node itself). The backup archive begins 2026-07-26 (first run 20260726-063202, pruned; backup.log line 5). All 14 CURRENTLY retained runs, 2026-08-10 through 2026-08-23, carry it — verified individually. This is NEVER-WIRED, not a regression: claude/tools/claude_turn_capture.py has carried zero redaction across its entire tracked history (b3a85cb7 2026-08-14, 993f9f00 2026-08-14, 5fe467e4 2026-08-16 — grep for redact/scrub/sanitiz/mask/secret returns 0 hits at HEAD). The archive path itself was pinned into the DEV tree deliberately on 2026-08-16 04:49:52 by f68876cf.

Proposed fix. Treat both credentials as disclosed and rotate them now: revoke the GitLab PAT (memory records the canonical store as ~/.env with copies to sync, and the replacement flow via the Todoist 'Code'/'glab' task) and rotate the Google Drive OAuth client secret. Rotation alone is not the fix — the archive keeps whatever the graph holds, so also (a) purge the offending turn node from orchkg and re-snapshot, (b) add a redaction pass to the turn-capture ingestion path keyed on the same prefix corpus scripts/check_secret_leaks.py already defines (glpat-/ghp_/sk-ant-/GOCSPX-/AKIA/hf_) so credentials never reach the graph, and (c) encrypt the archive at rest or move it out of the checkout (see GAP-BKP-03). Do NOT rely on rotating and leaving the old value in 14 snapshots — a revoked GitLab PAT is stil…

Origin: R2·GAP-BKP-01 · Files: claude/tools/claude_turn_capture.py, env, home/mohamed/.env, home/mohamed/workspace/orchestrata-ultimate-architecture/claude/tools/claude_turn_capture.py, home/mohamed/workspace/orchestrata-ultimate-architecture/secrets/env.sops.env

Tests & Verification

OA-011 — 1,074 generated smoke tests cannot fail — no assertion plus a blanket exception swallow

🔴 FATAL · false-green · ✅ confirmed · evidence: measured · state: ``

Every one of the 1,074 generated *_smoke tests has zero assert statements and catches every Exception from the code under test with a handler whose entire body is return, so it reports PASS regardless of what the code returns or raises.

Proposed fix. Fix the generator, not the 271 generated files: scripts/generate_pytest.py:1387-1441. A smoke test that swallows everything is worth nothing — either (a) drop the blanket handler so an unexpected exception fails the test and keep a narrow except TypeError only for the dummy-argument mismatch the comment actually justifies, plus an explicit pytest.fail when construction succeeds and the call raises anything else, or (b) delete the smoke template entirely and keep only the _interface tests, which do discriminate. Then regenerate. Do NOT hand-patch the 1,074 sites.

Origin: R1·TESTS-FALSEGREEN-001 · Files: reconcile.py, scan.py, scripts/generate_pytest.py, test_template_cannot_fail.py, tests/generated_agents/test_prolog_bridge_generated.py, tests/generated_agents/test_volks_codedirector_review_checks_generated.py

Specs & Requirements

OA-022 — SPEC-007 declares 11 engineering constitutional articles; the enforced constitution declares 12 ethics articles with zero name overlap

🔴 FATAL · contradiction · ✅ confirmed · evidence: measured · state: ``

SPEC-007 Prolog Governance (Status: Complete) specifies a constitution of 11 engineering rules that shares not one article name with the 12-article ethics constitution that src/orchestrata_ultimate/prolog/constitutional.pl actually defines and that intent_policy.pl queries at runtime.

Proposed fix. Do not resolve by guessing. Present both sets to the human owner: the code+checklist ethics constitution (12 articles) is what governs live decisions, so SPEC-007 §'The 11 Constitutional Articles' and SPEC_INVENTORY §Governance are the two documents that must be rewritten to the 12-article ethics set — and the 11 engineering rules they currently hold need a new home (they are already stated in CLAUDE.md Key Rules and AGENTS.md, so the honest fix may be deletion rather than relocation). Then add a gate that asserts every constitutional_article/4 fact has a matching spec table row and vice versa, so the two can never drift again.

Origin: R1·SPECS-CONTRA-001 · Files: specs/007-prolog-governance/checklists/requirements.md, specs/007-prolog-governance/spec.md, specs/SPEC_INVENTORY.md, src/orchestrata_ultimate/prolog/constitutional.pl, src/orchestrata_ultimate/prolog/intent_policy.pl

Unopened Surfaces

OA-028 — The only --strict enforcement of the standard has not executed its script since 2026-08-11 — 160+ consecutive infrastructure failures, 0 successes

🔴 FATAL · disconnection · ✅ confirmed · evidence: measured · state: production

.gitlab-ci.yml:271 is the single place in the system that runs the checker with --strict: uv run --no-project python scripts/architecture_checker.py src/ --strict. That job has failed at executor preparation on every pipeline since 2026-08-11T20:26:36Z, dying with 403 Forbidden fetching registry.gitlab.com/msamy/orchestrata-ultimate-architecture/ci:latest before a single script line runs. The architecture rule has had ZERO working automatic enforcement for 12 days. Round 1 never read GitLab pipeline history and so could not see this.

When it appeared. REGRESSION, dated to the hour. Last green: 2026-08-10T17:54:21Z (job 15815547499, sha 9ec6806e). First red: 2026-08-11T20:26:36Z (job 15842330164, sha 40efefa6). Continuous since — 12 days as of 2026-08-23. The cause is registry/runner-side (403 on the bearer token), not a repo commit: git log --since=2026-08-08 --until=2026-08-13 -- .gitlab-ci.yml docker/ returns no commits.

Proposed fix. Two separate fixes, and neither substitutes for the other. (a) Restore the runner's registry credentials so ${CI_IMAGE} pulls — this un-blocks lint, test and architecture-check together. (b) Independently, stop depending on a remote job for a stdlib-only AST scan: with ARCH-01 fixed, the local battery enforces the same rule with the same exit code and no image. Also add an alert on consecutive pipeline failure — 160 red pipelines produced no signal anyone acted on.

Origin: R2·ARCH-02 · Files: scripts/architecture_checker.py

Code & Architecture

OA-031 — The session fork silently destroys two context.json fields the src implementation writes

🔴 FATAL · drift · ✅ confirmed · evidence: measured · state: ``

claude/tools/session (loaded by session on PATH) reads and rewrites the same context.json as src/orchestrata_ultimate/session but drops state.goal.current_step and state.portfolio_goals, because its pydantic models declare neither field and default to extra='ignore'.

Proposed fix. session goal advance / goal step (src click CLI, cli/goals.py:239-276) are the only writers of current_step, and session set-goal (deployed fork) is what actually runs on PATH — so the plan-window cursor is destroyed the next time any fork command touches the file. Collapse to ONE implementation: make claude/tools/session a thin import of orchestrata_ultimate.session (shipped as a wheel into ~/.claude/.venv), or, if the fork must stay standalone, set model_config = ConfigDict(extra='allow') on its models AND add a test that round-trips a src-written context.json through the fork asserting byte equality. Do not leave two pydantic schemas writing one file.

Origin: R1·DUP-FORK-001 · Files: CLAUDE_HOME/tools/session_cli.py, claude/tools/session/models.py, claude/tools/session_cli.py, context.py, home/mohamed/workspace/orchestrata-ultimate-architecture/claude/tools/session/context.py, home/mohamed/workspace/orchestrata-ultimate-architecture/claude/tools/session/models.py

Contradictions

OA-037 — ~/.claude/audit/ existed and was fully populated for at least four months; a 235.5 MiB off-machine mirror survives

🔴 FATAL · contradiction · ✅ confirmed · evidence: measured · state: production

The round-1 open question "did ~/.claude/audit/ ever exist, or was it never built?" resolves against "never built" on direct artifact evidence. A mirror of this machine's ~/.claude at mseek:Workspace/sync/.claude holds a complete audit tree: 2,890 objects / 235.534 MiB, with all four subtrees SPEC-020 spec.md:876-886 mandates (sessions/, archive/YYYY-MM-DD/, findings/, subagent_findings/) plus enforcement_log.jsonl, and the sibling logs/file_operations.log at 23,399,294 bytes. 55 dated archive directories run 2025-12-28 through 2026-04-16. Archive filenames match REQ-020-206 ({session_id}_{epoch}.jsonl) byte-for-byte in shape: 8afbad68-f479-4c96-94df-3b44bdcbcb4c_1776384245.jsonl. The first line of findings/deception_log.jsonl is real stop_auditor.py output ({"type": "ACTION_DECEPTION", "severity": "CRITICAL", "pattern_matched": ...}) timestamped 2025-12-28T00:51:39. The mirror is provably this machine's ~/.claude: it sits beside sync/.claude/history.jsonl, sync/.claude/backups/.claude.json.backup.1776386638723, and sync/.claude/projects/-home-mohamed-workspace-orchestrata-ultimate-architecture/8afbad68-...jsonl. Locally the directory is gone and there is no displaced copy: ls ~/.claude/audit is ENOENT, no .claude.old/.claude.bak exists, and ~/.claude/.local/share/Trash is empty. CASE FOR "it existed and was lost" (strong): everything above, plus every top-level entry in the current ~/.claude carries a btrfs birth time of 2026-04-29 04:26:46 or later — the state directory was recreated wholesale that morning and audit/ did not come back. CASE FOR "treat it as never built" (weaker but real): the surviving evidence is entirely off-machine and on mseek:, which the user's own memory index records as the STALE remote (last object under sync/.claude is 2026-04-17T00:51Z); nothing in the repository, in any commit, in any installer, or in any local file records that the directory ever existed, so from the repo's point of view there is no prior art to restore. CONSEQUENCE EITHER WAY: REQ-020-208 "Archive data NEVER deleted" is currently false on this machine — 235.5 MiB of never-delete data is not here.

When it appeared. REGRESSION, not never-wired. Live and writing from at least 2025-12-28T00:51:39 (first deception_log entry) to 2026-04-16 20:47:56 (last mirrored audit write) and 2026-04-16 20:03:41 (last file_operations.log write). Lost at or before 2026-04-29 04:26:46, the btrfs birth time of the current ~/.claude and of every top-level entry inside it. The mirror cannot bound the upper end more tightly than 2026-04-17T00:51Z because the mseek: sync itself stopped then (newest object anywhere under sync/.claude). Zero audit writes since 2026-04-29 at the latest: each writer calls mkdir(parents=True, exist_ok=True) on its own sink before writing, so a single successful write since then would have re-creat…

Proposed fix. QUESTION FOR THE USER: given that the audit trail demonstrably ran (2,890 objects, 235.5 MiB, 2025-12-28 to 2026-04-16) and vanished with the 2026-04-29 recreation of ~/.claude — do you want SPEC-020 audit treated as a RESTORE or as a fresh BUILD? IF RESTORE: remediation is (i) re-register the five writers on the current delivery path, (ii) decide the sink root per C3-03, and (iii) pull the 235.5 MiB back from mseek: before that remote is retired, since REQ-020-208 forbids losing it — this is days of work, not hours, and it puts recovered pre-2026-04-29 data beside new data with a four-month hole in the middle. IF FRESH BUILD: remediation is only (i) and (ii), the historical 235.5 MiB is written off, and REQ-020-208's guarantee is knowingly broken once and re-baselined from today — which…

Origin: R2·C3-01 · Files: -home-mohamed/c55c93a3-f29c-4f8f-813f-69f2a3f7030f.json, Workspace/sync/.claude/audit/findings/deception_log.json, findings/deception_log.json, home/mohamed/.claude/projects/-home-mohamed/c55c93a3-f29c-4f8f-813f-69f2a3f7030f.json, home/mohamed/workspace/orchestrata-ultimate-architecture/specs/020-claude-code-harness/spec.md, sessions/7633c856-ebe3-4ce7-ab9c-1632594300d1.json

4. MAJOR register — 275, by subsystem

Docs & Knowledge (31)

Enforcement & Gates (30)

Specs & Requirements (30)

Knowledge Graphs (27)

Code & Architecture (27)

Unopened Surfaces (23)

Runtime & Deployment (22)

Tests & Verification (21)

Supply Chain & Payloads (20)

Write Sinks, CI & Dating (17)

Contradictions (16)

Measurement Verification (11)

5. Refutation ledger — 22 findings a coordinator rejected

Kept deliberately. A rejected finding is evidence about the analysis, and a claim that gets re-raised later should meet its own refutation first.

6. Appendix — MINOR and INFO (254)

7. Corrections ledger — 11 claims proven wrong

Claims this analysis made and then had to retract, including its own. Kept in the document because a corrections ledger is the only evidence that the verification layer works — an analysis that never corrects itself is not being checked.

R1 TOP-06 — FALSE

The deployed session CLI destroys goal.current_step and portfolio_goals on every write. Ranked step 1 of remediation.

Measured against the live 449,585-byte context.json, both fields appear 0 times. The round-trip that 'proved' the loss ran against state the analyst had seeded himself, then was reported as ongoing production loss.

Lesson. A proof executed against synthetic state is not a claim about production state. Every finding must declare which one it measured — this is why the round-2 schema made state_measured a required field.

R1 TOP-03 (prescribed fix) — NO-OP

Fix the assert-free smoke template by editing scripts/generate_pytest.py:1387-1441.

Rendering reads templates/smoke_test.jinja2 from disk via FileSystemLoader; the write-back is skipped when the file exists. The two copies are byte-identical today, but only the on-disk copy is ever read, so the prescribed edit would have changed nothing. The underlying defect (1,074 assert-free tests) is real and confirmed.

Lesson. Before prescribing a fix, prove the line you name is the line that executes.

R1 "1,531 architecture violations" — NOT REPRODUCIBLE

The codebase carries 1,531 violations of its own published architecture standard.

Measured at HEAD: 0 unwaived violations over 868 files (default root) and 934 (the CI root), with exactly 1 pre-waiver violation — the single documented KNOWN_VIOLATIONS entry. No configuration of the checker reproduces 1,531. The number was published with no method attached.

Lesson. A number without the command that produced it is not a measurement. The real architecture defect is not violation count — it is that the gate cannot fail (OA FATAL, --strict omitted) and the only strict runner has been dead 12 days.

R1 "the repo was left untouched" — FALSE

The read-only mandate held; git status shows the expected 14 entries.

11 files were written to reviews/, plus .cache/gates.json and .coverage. All are gitignored, so git status was structurally incapable of seeing them.

Lesson. git status cannot verify a read-only mandate. Use find -newermt. Round 2 adopted this and its own side-effect audit came back clean apart from expected cache writes.

R1 "gates.py is invoked by nothing" — FALSE

The 23-gate battery has no caller anywhere in the system.

.claude/hooks/single-gate-entrypoint.sh, registered at .claude/settings.json:51, is the live guard, and .cache/gates.json records 24 cached keys from a real run. The search that produced the claim covered deploy/, scripts/, .github/, pre-commit and pyproject.toml — and never .claude/hooks/.

Lesson. The defect is coverage and false-greens, not absent wiring. Searching every plausible location except one is indistinguishable from not searching.

R1 gate count (23 vs 24) — SETTLED — 23

The report used 23 and 24 interchangeably.

An AST parse of the GATES dict returns exactly 23 literal keys. The 24th key in .cache/gates.json is __ast__, the pre-gate AST-refresh fingerprint namespace — never a gate, never in selected.

Lesson. Two numbers for one thing is always a reader disagreement worth resolving; here it was benign, but the same shape is a real defect six times over in the requirement corpora.

R1 test-count and assert-free figures — CONFIRMED EXACT

33,259 collected tests, 1,074 of which cannot fail.

pytest --collect-only -q returns 33259/33399 tests collected (140 deselected) in 14.59s, exit 0, and independently reconstructs from a per-directory sum. The 1,074 figure is confirmed three ways and is not an undercount.

Lesson. Recorded because it is the control arm: round 2 was sent to break these numbers and could not. Asserting without measuring was still wrong, even where the assertion held.

This analysis — finding id space — FALSE

Agent-local finding ids are usable as report ids.

Two round-2 lenses independently minted GS-01 through GS-14 for entirely different defects; 15 ids collided in total. All findings were re-keyed to a global OA-NNN space with agent ids demoted to provenance.

Lesson. This is the same two registers, one id space defect the analysis found in the project's four ADR registers. A report that catalogues a defect while committing it has not understood it.

R1/R2 "the SPEC-020 audit trail was never built" — REFUTED

~/.claude/audit/ is absent at both candidate roots and every artifact capable of dating it points to never-created, so SPEC-020's audit trail was specified and never implemented.

The trail ran. An off-machine copy holds 2,890 objects totalling 235.534 MiB spanning 2025-12-28 to 2026-04-16, alongside a settings.json (ModTime 2026-04-16 18:45:14) that registers five audit writers. The directory vanished with the 2026-04-29 recreation of ~/.claude. Every local artifact pointed at 'never built' only because no local artifact can see before 2026-07-28 — the three tools that would normally date it are all structurally blind to claude/.

Lesson. Absence of evidence inside a bounded observation window is not evidence of absence. The analysis correctly flagged that its tools were blind rather than concluding from their silence — and the swarm sent to widen the window found the data. This is what the unverified state is for: it is not a soft 'probably wrong'.

This session — regenerating a committed generated artifact — FALSE — silently destructive

Running the generator command documented for plans/ast-ultimate.json reproduces it.

--source src/orchestrata_ultimate (the command in the file header and cited by ast_live_sync.py:101) produces 868 modules. The committed artifact has 2,976 across six roots, and carries 3,680 runtime_calls entries merged in afterwards by a separate tool. A naive regenerate narrowed the artifact by 70% and dropped every runtime edge — and freshness_guard.py:12 documents that exact incident ('derive_rtm fell 1055->575'). Recovered by reading root_path/extra_roots off the committed copy and re-running build_runtime_callgraph.py reaugment.

Lesson. A generated artifact whose documented command does not reproduce it is a defect in its own right — the header, ast_live_sync.py:101, and the artifact disagree. Before regenerating any committed artifact, read its own provenance fields and check for post-merge passes; the documented command is a claim, not an oracle.

This session — binary-file grep — FALSE

grep -rl <needle> backups/ returning nothing means the needle is absent.

GNU grep suppresses output on files it detects as binary, so the command printed nothing whether the answer was 'no' or 'I could not look'. grep -a on the same file returns 6 matches. A true FATAL was nearly rejected on that silence.

Lesson. The oracle-that-cannot-fail pattern is not only in the codebase under analysis — it caught the analysis itself. Prefer a method with no give-up path: the analysts used in-process bytes.count(), which has no binary heuristic.

8. Decisions reserved to the user — 6 curated + 27 raised by the swarms

Each of these changes what gets built. None is resolvable by measurement — the swarm that investigated them was given a schema with no verdict field, so it could gather evidence for both sides and nothing else. Final say is the user's.

D-01 — Are the project's PreToolUse/Stop guards dead everywhere, or is their inertness scoped to sessions rooted outside the project?

• Side A. DEAD LAYER — inertness is reproducible in-session; a round-2 analyst independently observed the registered guards not firing on their own foreground pytest run.
• Side B. SCOPING BUG — a 900 MB transcript scan split by session PROJECT ROOT shows guard delivery tracks the root, not subagent-ness, which would make this a narrower fix.

What would settle it. A controlled main-session invocation from the project root of a command the guard is known to match, with the hook's own stderr captured.

Consequence. Side A means the enforcement layer must be rebuilt and every 'guarded' claim in the docs is false. Side B means one scoping fix restores it and the docs are right for the normal case.

Why it is yours. It determines whether the enforcement layer is rebuilt or repaired — a scope call, not a fact.

D-02 — Which of the four ADR registers is authoritative?

• Side A. The WIKI register (25 decisions) — it is what the production graph actually serves, and its decisions are marked ratified.
• Side B. The REPO register docs/adr/ (38 decisions, 0001-0038) — it is version-controlled with the code it governs and is the larger, newer set.

What would settle it. Nothing measurable. All 25 overlapping ids carry different decisions in each register; a three-way detector returns 25 AMBIGUOUS_COLLISION + 13 MISSING_FROM_GRAPH.

Consequence. Whichever loses must be renumbered or namespaced. Ingesting the repo set as-is would either raise AdrImmutabilityError or silently overwrite a ratified wiki decision.

Why it is yours. Ratification is an authorship act. No amount of measurement decides which decision record binds the project.

D-03 — Which requirement corpus is authoritative, given six readers spanning 3,087 to 7,245 ids?

• Side A. reports/rtm-evidence.json (7,245) — the widest, and what the RTM evidence generator produces.
• Side B. docs/rtm.json (3,087) — the narrowest, but what check_generated_artifacts.py already calls 'the ONE materialized traceability corpus'.

What would settle it. A decision, not a measurement. Both RTM artifacts declare "verified": false, and both disagree with their own declared row counts.

Consequence. Every requirement-coverage percentage in the project currently has an undeclared denominator. Until one corpus wins, no coverage number means anything.

Why it is yours. Choosing a corpus sets the denominator for every future traceability claim.

D-04 — Is architecture/layer-dependency-rules.md superseded, or is it the intended target model?

• Side A. SUPERSEDED — it specifies a 6-layer model with packages (domain/, infra/, messaging/, knowledge/) that do not exist, and its 'Enforcement Mechanisms' section proposes extending a checker that has enforced layer rules for months.
• Side B. TARGET STATE — it is a design record describing where the architecture was heading; the shipped LAYER_ASSIGNMENTS is the compromise, not the intent.

What would settle it. Your intent. Neither document references the other, so the tree records no supersession either way.

Consequence. Side A means add a supersession header (or delete and fix 3 inbound refs). Side B means the shipped model is the drift and the checker should be moved toward the document.

Why it is yours. The analyst explicitly declined to resolve it by deletion: it is a design record, and which model is 'right' is an architecture decision.

D-06 — Two formatters are declared on one tree and they disagree on 401 files. Which one is authoritative — black or ruff format?

• Side A. BLACK — it is what actually runs. scripts/gates.py:421 invokes black -q src/ tests/ scripts/ before every gate battery, so the tree is black-formatted today: black --check tests/ reports 0 files needing change.
• Side B. RUFF FORMAT — it is what the repo declares. .pre-commit-config.yaml:7 registers ruff format as the formatting hook, and ruff is already the linter, so one tool would own both. Measured cost of switching: ruff format --check tests/ reports 401 of 1,774 files would be reformatted.

What would settle it. Nothing measurable — both run correctly, they simply disagree (chiefly on collapsing implicit string concatenation). The tree is consistent under black only because the pre-commit hook that would run ruff format has never executed.

Consequence. Picking ruff format means a 401-file reformat commit and dropping black from gates.py:421. Picking black means deleting the ruff format pre-commit hook so it cannot churn the tree if pre-commit is ever repaired. Leaving both declared guarantees a 401-file diff the first time the dormant hook wakes up.

Why it is yours. Tooling choice, not a defect. NOT a new discovery: the user's own memory (feedback-push-deploy-wire-automatically, 2026-08-14) already records this exact split — 'orchestrata's arm asserted ruff format --check in a repo that formats with black... it demanded 439 files be reformatted, so it could only ever pass by breaking the repo.' The count is 401 today. It has been known and unfixed for 9 days, and it is recorded there as one of the two ways ship lies about being verified. That makes it a standing decision the user has already seen, not a finding.

D-05 — SPEC-020's ~/.claude/audit/ trail DID exist and was lost. Restore the 235.5 MiB of historical findings, or write them off and rebuild from today?

• Side A. RESTORE — the trail demonstrably ran (2,890 objects, 235.534 MiB, 2025-12-28 to 2026-04-16) and vanished with the 2026-04-29 recreation of ~/.claude. The wiring that drove it is recoverable verbatim from an off-machine copy registering five writers. REQ-020-208 states archive data is NEVER deleted — a guarantee that is false today and stays false if the data is abandoned.
• Side B. FRESH BUILD — the surviving evidence sits entirely on the mseek: remote, which your own memory index records as STALE. The data is four months old and describes sessions predating the current architecture; recovering it produces a corpus with a four-month hole in the middle.

What would settle it. EXISTENCE IS NOW CLOSED — the swarm measured it, and round 1's premise that the trail was never built is refuted. What remains is a judgement only you can make about whether pre-2026-04-29 findings have value, plus one fact nobody here can measure: whether mseek: is scheduled for retirement.

Consequence. RESTORE costs days: re-register five writers on the current delivery path, settle the root-location question, and pull the data back before mseek: goes away. FRESH BUILD costs only the wiring, but REQ-020-208's never-delete guarantee is then knowingly broken once and re-baselined from today.

Why it is yours. The original question — did it ever exist — was answered by measurement, and the answer is YES. What is left is a value judgement about four-month-old data on a remote you have recorded as stale.

Additional questions the swarms raised

Surfaced by a coordinator or the gap consolidation rather than curated above. Same rule: evidence on both sides, no verdict.

S-01. What is rtm/ — a frozen historical record to be excluded from all future sweeps, or a retired tree to be deleted?

• Side A. FROZEN RECORD. It is a handover snapshot of the April-2026 porting phase (entered 70b68322, 'Completed initial porting phase and setup'), and rtm/rtm.json is a dated corpus whose value is being a point-in-time record. Commit fb167c13's own stated policy already recognises this class: 'Excluded by design: frozen AST snapshots ... Rewriting a historical record falsifies the history it exists to preserve.' plans/tools_useful_to_plan.md:413-433 still describes parts of it as live tooling.
• Side B. RETIRED. Nothing has invoked it since 2026-07-06 (48 days, measured from rtm/scripts/pycache mtimes). It carries 6 basename forks of live scripts and a THIRD session_cli.py, all fork-then-diverge hazards. scripts/check_incus_not_docker.py:114 already quarantines two of its files as a 'frozen handover artifact, invoked by no runner' and recommends deleting them. 892 of its 14,881 RTM entries point at 24 source files that no longer exist, and three corpus-wide migrations have mechanically rew…

What would settle it. Whether anyone will ever need to read rtm/ as a record of what the port looked like. If yes it must be added to the migration-exclusion list the way frozen AST snapshots already are, and its 60 modules declared out of AST scope. If no it is 81 files of collision hazard. Only the owner of the porting history knows.

Consequence. FROZEN: sweeps stop rewriting 15k lines of a file nothing reads, but the six script forks and the third session_cli.py stay on disk and will be found again by the next agent grepping a bare filename. RETIRED: the collision hazard and the fork-then-diverge risk are gone permanently, and the April-2026 port record is gone with them — recoverable only from git history.

S-02. Which of the four materialized RTM corpora is authoritative — docs/rtm.json (3,087 ids), rtm/rtm.json (4,467), plans/rtm.json (5,121), or reports/rtm-evidence.json (7,245)?

• Side A. docs/rtm.json. It is the one already registered in the artifact registry, the one scripts/check_generated_artifacts.py reads to attribute requirement ids, and the one the gate's own docstring calls 'the ONE materialized traceability corpus this project already maintains'. Choosing anything else means rewriting that gate's attribution path.
• Side B. reports/rtm-evidence.json. It is the widest (4,158 more ids than docs/rtm.json), the newest (regenerated 2026-08-15 vs 2026-08-12), and has a named, running generator with a declared default output path (generate_rtm_evidence.py:279). docs/rtm.json carries "project": "" and its own write path is documented in _pipeline.py:331-335 as having polluted this repo's tracked corpus once via a stray unscoped invocation.

What would settle it. Which corpus the project intends its requirement attribution to be computed FROM. Nothing in specs/ decides it — git grep 'rtm/' -- specs/ returns nothing, so the choice has no recorded owner. Note also that the harvester feeding one of them is blind to claude/ and scripts/ (607 requirement citations in unscanned roots, per the base dossier), so 'widest' is not automatically 'most complete'.

Consequence. Whichever is chosen, the other three must become derived or deleted, and the gate's 'the ONE' wording must either become true or be replaced by a line that prints which corpus was read and its id count. Choosing docs/rtm.json keeps every requirement attribution computed from the narrowest of four sets — 4,158 ids the system knows about will never appear in a Serves: clause. Choosing reports/rtm…

S-03. Is tasks/ a live work queue or a completed-work archive?

• Side A. LIVE QUEUE. 30 briefs read as active instructions, SPEC-033 §9 references them as the delegation surface, and factory/contracts/models.py:8 cites one in a docstring. Eight §9 rows have no brief at all — including B4b, which §9 itself calls the 'TRUE LONG POLE' — which is a gap only if the surface is meant to be complete.
• Side B. ARCHIVE. 297 of 307 named code paths and 32 of 32 deliverables for the twelve rows §9 still marks 'to-build' already exist, so the b-series work shipped. No brief carries a status marker (0 of 30), there is no index, and no runner or gate reads the directory. 70% of its bytes are a 124-day-old generated review report of a module that has since been renamed.

What would settle it. Whether new work will be dispatched from tasks/ again. Every finding on this surface flips with the answer: as an archive the banned -n auto and monkeypatch instructions in the three coverage briefs are harmless history and the dead review report can stay; as a queue those briefs are live instructions to violate the project's own bans, and 30 briefs need status markers.

Consequence. QUEUE: the three coverage briefs must be rewritten before any agent is pointed at them (GAP-17), all 30 briefs need STATUS fields, and the 8 unbriefed §9 rows are a real gap. ARCHIVE: it needs a dated README saying so, tasks/core-threadpool/review-report.json can go, and GAP-16's spec-status gate should read the tree rather than the briefs. Today it is neither, which is the worst state: live-look…

S-04. The 403 on the CI image has stopped all remote verification for 12 days. Restore the registry credentials, or move enforcement fully local and stop depending on remote CI?

• Side A. RESTORE THE REGISTRY. One fix un-blocks lint, test and architecture-check together and returns the project to the CI posture it was designed with. The failure is credential/visibility-side, not a repo defect (no commit in the 2026-08-08..08-13 window touches .gitlab-ci.yml or docker/), so it is likely a small change to runner credentials or registry visibility.
• Side B. MOVE ENFORCEMENT LOCAL. scripts/gates.py is already the battery this project actually runs, already has 23 gates, is already protected by a live guard, and needs no image at all for a stdlib-only AST scan. The remote has produced no signal that anyone acted on for 12 days across 160+ red pipelines, which is evidence that remote CI is not where this project's enforcement actually lives.

What would settle it. Whether the GitLab account still needs a working pipeline for anything other than these jobs — and whether the registry access can be restored durably rather than re-breaking on the next token rotation. Note build-image is rules-gated on changes: docker/Dockerfile.ci, so it cannot self-heal the image.

Consequence. RESTORE: lint, test and architecture-check return, but nothing yet alerts on the next 160-pipeline silence, so the same 12-day blind window can recur unnoticed. LOCAL: enforcement becomes trigger-dependent on an agent invoking the battery — and the base dossier already records that gates.py has no automatic trigger — so the project would be trading a dead remote gate for a manually-invoked local…

S-05. What happens to .github/workflows/ci.yml — an actively-maintained GitHub Actions workflow on a repository whose only remote is GitLab?

• Side A. PORT IT. It carries 8 checks — both pyright ratchets, the Prolog gate, the AST untyped ratchet, check-traces, the async gate and more — whose GitLab coverage is unverified. It was edited as recently as 2026-08-18 with dated baseline tightenings, so someone is still investing in it. Deleting it discards those checks unless each is first confirmed present in .gitlab-ci.yml.
• Side B. DELETE IT. It has never been able to run: both CI files were created the same day, 2026-04-11, one for each forge, and origin has only ever been git@gitlab.com. A workflow that cannot trigger produces no history, and no history reads as green rather than as absent — which is exactly how the pyright-0 invariant came to have no runner at all without anyone noticing.

What would settle it. An inventory of which of its 8 checks exist in .gitlab-ci.yml or scripts/gates.py. I verified only the pyright path (absent from both). The other 6 are unexamined and that inventory is a prerequisite either way.

Consequence. PORT: 8 checks gain a real runner, but they land on the GitLab pipeline that is currently 100% red (see the previous decision), so they will not execute until that is fixed. DELETE without the inventory first: any check unique to it is silently lost, and check_feature_loss.py detects loss-by-deletion only for FILES, not for capabilities. Leaving it is the status quo that produced GAP-07.

S-06. architecture/layer-dependency-rules.md contradicts the shipped layer model on memory, cli, integrations and four packages that do not exist. Mark it superseded, or delete it?

• Side A. MARK SUPERSEDED. It is a design record from 2026-04-11 with 3 inbound references, one of which (plans/pipeline-automation-plan.md:745) cites it as a live standard. Deleting a design record destroys the reasoning behind a layering decision, and architecture-standards.md's preamble makes the CHECKER authoritative over itself but says nothing about this older document — there is no rule in the system that decides between them.
• Side B. DELETE IT. It has contradicted the shipped model for 4 months, it tells a reader that packages named domain/, infra/, messaging/ and knowledge/ exist when none do, and it instructs 'Extend architecture_checker.py (461 LOC) to enforce layer rules' — work completed months ago in a file now 689 lines. Its one formal review, on 2026-07-06, mis-measured it as absent (git falsifies that: git cat-file -e 6c8a935a:architecture/layer-dependency-rules.md exits 0) and deleted the checker's REFERENCE to…

What would settle it. Whether the document's layer reasoning still has value independent of its now-wrong package names. Only whoever owns the design record can say. Either answer requires fixing the 3 inbound references.

Consequence. SUPERSEDED: the contradiction stops misleading readers but two layer tables remain in the tree, and the 2026-07-06 review shows that a stale document survives a formal review when the reviewer measures the wrong thing. DELETE: one authority remains — but architecture/modular-monolith.md contains a full Layer 0-5 narrative that was NOT diffed against the shipped model, so a fourth authority may al…

S-07. SPEC-028's checklist and configs/spike-profiles.yaml disagree on three default model assignments. Amend the spec to the operational values, or move the config back to the spec'd Claude models?

• Side A. AMEND THE SPEC. src/orchestrata_ultimate/llm/config.py:3 already declares the YAML 'the single source of truth', the YAML carries a dated in-file rationale for the 2026-07-14 change (the DeepSeek native account returns HTTP 402), and the config is demonstrably live — read by llm/config.py:94-107 and factory/decision/authority.py:135, with tests. The spec checklist is the only side that has not moved.
• Side B. MOVE THE CONFIG BACK. The three items are UNCHECKED in the spec, so on the spec's own terms they are neither satisfied nor withdrawn, and the standing project ruling is that specs are authoritative for design and contract choices. openrouter/minimax-m3 for U:Cx and U:Ar and qwen3-coder-next for J:Junior are three different vendors from what the spec requires, and the substitution was made for a billing failure, not a capability judgement.

What would settle it. Which models the user actually wants running behind U:Cx, U:Ar and J:Junior today. That is a cost and capability call nobody but the user can make, and the 402 that forced the original substitution may or may not still apply.

Consequence. AMEND: the operational values become the record and TEST-028-017/018/019 can be checked and enforced. MOVE BACK: the models change under live agents and the 402 that triggered the substitution must be resolved first. Doing neither continues a 48-day-old contradiction that has already been re-measured twice, with the one test that could have failed on it written to describe the divergence instead…

S-08. The SPEC-020 audit trail demonstrably ran (2,890 objects / 235.534 MiB, 2025-12-28 to 2026-04-16) and vanished with the 2026-04-29 recreation of ~/.claude. Is this a RESTORE of a lost capability or a fresh BUILD that writes off the historical data?

• Side A. RESTORE. The trail existed, the wiring that drove it is recoverable verbatim (mseek:Workspace/sync/.claude/settings.json, ModTime 2026-04-16 18:45:14, registers five writers at lines 18/69/78/96/125), and REQ-020-208 states archive data is NEVER deleted — a guarantee that is false today and stays false if the 235.5 MiB is abandoned. The data is one remote-retirement away from being genuinely unrecoverable.
• Side B. FRESH BUILD. The surviving evidence is entirely off-machine on mseek:, the remote the user's own memory index records as stale (newest object anywhere under sync/.claude is 2026-04-17T00:51Z). The data is four months old and describes sessions that ended before the current architecture existed. Recovering 235.5 MiB of historical deception findings produces a corpus with a four-month hole in the middle, and nothing in the repository, in any commit, or in any installer records that the directory…

What would settle it. Two read-only commands already re-run and reproducible in under two minutes: rclone size mseek:Workspace/sync/.claude/audit and rclone lsl mseek:Workspace/sync/.claude/audit. Those settle EXISTENCE, which is now closed. What settles the choice is a judgement only you can make about whether the pre-2026-04-29 findings have value, plus one fact I cannot measure: whether mseek: is scheduled for…

Consequence. RESTORE costs days, not hours: re-register the five writers on the current delivery path, settle the root question (decision #2), and pull 235.5 MiB back before mseek: goes away — landing recovered data beside new data with a four-month gap between them. FRESH BUILD costs only the wiring, but REQ-020-208's only never-delete guarantee is then knowingly broken once and re-baselined from today, whic…

S-09. When the audit writers are re-wired, does the trail live at ~/.claude/audit/ (what SPEC-020 says in 12 places and what the 2025-12→2026-04 data used) or at ~/.claude/plugins/data/orchestrata-orchestrata/audit/ (where the CLAUDE_PLUGIN_DATA branch sends it under the current plugin delivery path)?

• Side A. ~/.claude/audit/. SPEC-020 spec.md names that literal path 12 times and REQ-020-124, 200, 204 and 205 are checked [x] against it. The 235.5 MiB of historical data was written there, so recovered data and new data share one tree with no path change. Choosing this means removing or overriding the CLAUDE_PLUGIN_DATA branch for audit specifically.
• Side B. Plugin-data. The writers' own comment gives the rationale — 'a plugin's install dir is replaced wholesale on update, so anything written inside it is lost' — and the branch is already live and proven: intercept_edit.py, using the identical idiom, wrote to ~/.claude/logs/ until the cutover (birth 2026-08-14 11:29:16) and to ~/.claude/plugins/data/orchestrata-orchestrata/logs/ since (birth 2026-08-22 01:00:35, still writing at 2026-08-23 12:39). Choosing this means the restored trail lands there…

What would settle it. The factual half is already settled — intercept_edit.py ran this experiment for you on 2026-08-22 and the answer is plugin-data. Only the policy half is open, and nothing measurable decides it: it is a choice about whether never-delete data may live adjacent to a directory the writers' own comment describes as replaced wholesale on update. If you want confirmation for the audit writers specifical…

Consequence. ~/.claude/audit/ contradicts the stated rationale for the CLAUDE_PLUGIN_DATA branch and requires an audit-specific exception in five files. Plugin-data requires amending SPEC-020 at all 12 locations and rewriting REQ-020-124/200/204/205, and places REQ-020-208's NEVER-deleted guarantee inside a plugin data directory — which then needs an explicit statement of why plugins/data survives a plugin up…

S-10. The project enforcement layer fires in BOTH main sessions and delegated subagents when the session is launched inside the repo, and in NEITHER when launched from $HOME. Should TOP-04 be reclassified as a launch-practice failure, or should the guards be re-anchored so they arm regardless of launch directory?

• Side A. Reclassify as launch practice. No code changes. The guards are intact and correct — 1,511 Stop firings and 197 SessionStart executions through 2026-08-20, 74+175 genuine subagent denials, and a live control run proving the guard code still denies correctly when fed a payload today. The project's own claude/skills/shell-guards/SKILL.md:105-109 already documents this behaviour, committed 2026-08-21. The remediation becomes a launch rule plus a loud startup warning.
• Side B. Re-anchor the guards. Relying on launch discipline is what produced a three-day enforcement outage that no gate, log or check surfaced — and the only record of it is a hand-written skill paragraph nobody consulted. Moving the registrations to a scope the harness always loads (user-level settings with absolute paths, or the plugin) makes them unconditional.

What would settle it. One controlled pair, which only you can run because it requires a top-level interactive session: launch claude with cwd = /home/mohamed/workspace/orchestrata-ultimate-architecture and issue : pytest -n 4; then repeat from /home/mohamed. Deny-then-allow confirms the scope explanation; allow-then-allow means a second independent failure exists. CAUTION: launching from the repo root fires 7 Sess…

Consequence. RECLASSIFY: every round-1 finding phrased as 'the guard did not fire' must be re-read as 'this session was $HOME-rooted', and every finding derived from that must be re-taken from a repo-rooted control run before it is acted on — the whole round-1 swarm and this one ran unguarded from /home/mohamed. RE-ANCHOR: the guards' blast radius changes from this repo to every project on the machine, so eac…

S-11. Is claude/settings.json the intended source of truth for user-surface hook registration, or is it dead config to be deleted?

• Side A. SOURCE OF TRUTH. It carries the exact five registrations that were live on the machine on 2026-04-16 and is the last in-repo record of the working audit wiring. Making deploy/install-claude-config.sh deploy or merge it re-lights all five writers at once and makes the loss impossible to repeat — and would also fix the fresh-machine bootstrap, which currently crashes: patch_settings.py raises FileNotFoundError at line 151 against a prefix with no settings.json, and that is install-claude-config.s…
• Side B. DEAD CONFIG. git log -S 'claude/settings.json' -- deploy/install-claude-config.sh returns empty — no installer version has ever copied it, no code reads it, and its registrations froze on 2026-07-27, before the cutover. Under the standing dead-config ruling it must be deleted or wired, and wiring it re-introduces a third registration authority beside settings.hooks.json and the plugin — the exact two-authorities pattern found in four other domains.

What would settle it. The installer already carries the oracle at lines 458-459: register_hooks.py "$PREFIX/settings.hooks.json" "$PREFIX/settings.json" --check --plugin auto || fail 'a declared hook is not registered in settings.json — deployed but not wired'. Whether that gate turns red when the five writers are declared is a one-command experiment that decides whether they are in scope for the current delivery pa…

Consequence. SOURCE OF TRUTH: a fresh machine would be seeded with a 2026-07-27 hook set that duplicates 31 plugin registrations and re-registers hooks the cutover deliberately dropped — so its 12 entries must be reconciled against settings.hooks.json's 31 FIRST or every event double-fires. DEAD CONFIG: the fresh-machine bootstrap still needs a seed from somewhere, the five audit registrations must be authore…

S-12. Which document is authoritative about where hooks are registered: SPEC-020 (~/.claude/settings.json, zero mentions of the plugin) or claude/README.md + register_hooks.py + gates.py (the plugin's hooks/hooks.json, with settings.hooks.json as a compile-time declaration)?

• Side A. SPEC-020 IS AUTHORITATIVE. It is the governing specification, marked P0/Implemented, and defines a hook at spec.md:231 as 'A Python script registered in ~/.claude/settings.json'. If that stands, the live system is in drift on its central mechanism: 31 of the 32 hooks running today are registered somewhere the spec does not name, and by the spec's own definition they are not hooks.
• Side B. THE CODE AUTHORITIES ARE. The plugin chain is measured and works: 31 declarations produce exactly 31 plugin registrations, the installed plugin is pinned to gitCommitSha 143310ec = HEAD = PROD, and the binary loads it. grep -rn 'settings\.hooks\.json' specs/ returns 0 across all 79 spec directories and SPEC-020 never mentions a plugin — so spec.md:36 and :231 are simply stale text that has already produced one false alarm (round 1's contradiction #2).

What would settle it. For the factual half — whether the binary reads settings.hooks.json at all — one probe closes both loopholes my passive measurement leaves open: add a uniquely-named marker hook (SessionStart running sh -c 'date >> /tmp/shj-probe.log') to ~/.claude/settings.hooks.json ONLY, present in neither ~/.claude/settings.json nor the plugin manifest, then start one fresh claude session. Zero lines = not…

Consequence. SPEC-020 AUTHORITATIVE: the spec must be amended to describe plugin delivery with requirement IDs pinning it, or registration moves back into settings.json — and until then no statement in specs/ about hooks can be trusted. CODE AUTHORITIES: SPEC-020 §36 and §231 are stale and must be corrected along with a supersession note in plans/spec-020-drift-ledger.md:37, whose 'claude/settings.hooks.json…

S-13. Is the permissions block inside claude/settings.hooks.json a DECLARATION the deploy is meant to apply, or inert documentation of a hand-maintained file?

• Side A. DECLARATION. It grants 9 Bash allow rules including the wildcard Bash(incus *) and sets defaultMode 'auto'. If it is meant to apply, it is unwired today — 'permissions' appears 0 times in register_hooks.py, gen_plugin.py and patch_settings.py — and a fresh machine gets 0 of the 9 rules and loses defaultMode='auto' silently.
• Side B. INERT DOCUMENTATION. patch_settings.py's own docstring states the design intent: 'settings.json is hand-maintained and holds personal preferences (theme, model, notification channels) that a deployment has no business touching.' On that reading a permission grant delivered by a deploy script rather than by the user is the defect, and the block should be deleted from the declaration rather than wired.

What would settle it. Add one assertion to register_hooks.py --check comparing declared permissions against $PREFIX/settings.json and observe that it passes today (all 9 declared rules are a strict subset of the live 26 — set difference is []), then break one rule by hand and confirm the assertion CAN fail. Alternatively, temporarily remove one rule (e.g. Bash(docker version *)) from both live files while leaving it i…

Consequence. DECLARATION: the block is silently failing to grant Bash(incus *) and defaultMode='auto' on any machine the installer touches other than this one, and the fix is to extend patch_settings.py to merge declared permissions and give register_hooks.py --check an oracle that can fail. INERT: the key must be deleted or moved out of the declaration, because leaving a permissions/defaultMode key in a file…

S-14. Is a SPEC checklist a record of what was BUILT, or a record of what is CURRENTLY TRUE?

• Side A. RECORD OF WHAT WAS BUILT. The 240/240 in specs/020-claude-code-harness/checklists/requirements.md is then correct as it stands and needs no edit — the requirements WERE implemented, the code satisfying them is present and correct, and what failed is deployment wiring, which a requirements checklist arguably does not track.
• Side B. RECORD OF WHAT IS CURRENTLY TRUE. Nine entries are false today — REQ-020-124, 200, 203, 204, 205, 208, 209 plus CONST-IV-002 and CONST-IX-006 — and they survived an edit committed 2026-08-03 with the sink already four months dead. A checklist asserting a live capability that has not existed since April is what let round 1 read the 240/240 as fabrication.

What would settle it. Whether any gate in scripts/gates.py consumes the checkbox state. If none does, the boxes are decoration and only the 'record of what was built' reading is available; if one does, the 'currently true' reading is forced. That is a grep over gates.py against the checklist paths, and it settles the question mechanically.

Consequence. BUILT: nothing in specs/ can ever be cited as evidence of live behaviour, and plans/spec-020-drift-ledger.md becomes the only current-state authority — which must be stated in the checklist header so the next reader does not repeat round 1's inference. CURRENTLY TRUE: the nine entries must be unchecked today and the checklist needs a re-validation trigger, because it survived a 2026-08-03 edit wi…

S-15. Is rtm/ a live surface or a retired staging area? It holds two more requirement corpora (4,467 unique ids, plus a third framing at 4,311) and a 36-file parallel toolchain of which 30 files exist nowhere else and 5 diverge from scripts/.

• Side A. LIVE. The 30 only-in-rtm scripts include the only copies of generate_rtm.py, reconcile_rtm.py and parse_requirements.py, and rtm/reconciliation_report.json is the output of one of them — so at least one has run. Deleting the directory deletes capability. On this reading the two corpora are additional candidates for the authoritative-corpus question and the 5 divergent scripts must be collapsed onto single copies.
• Side B. RETIRED. rtm/scripts/serialize_codebase_ast.py and rtm/scripts/session_cli.py last changed 2026-07-27 against scripts/serialize_codebase_ast.py at 2026-08-19 — 23 days of one-sided drift, and plans/decisions-2026-07-06.md:27-30 already recorded a 'FORK RESOLUTION' about rtm/scripts imports 48 days ago that was never carried out. Deleting removes two more answers from the corpus disagreement at zero cost.

What would settle it. For each of the 30 only-in-rtm scripts, an execution-provenance check: does any tracked output artifact carry its signature, and does any hook, gate, CI stage or ship stage invoke it? Anything with neither is answerable by deletion; anything with either must be wired to a single copy. Separately, run the generator rtm/rtm.json and rtm/requirements.json claim and diff its output against the commit…

Consequence. LIVE: the authoritative-corpus choice widens from two candidates to four, the 4,467-vs-4,311 disagreement inside rtm/ must be reconciled first, and the 291 duplicate rows in rtm/requirements.json point at a producer that is still producing them. RETIRED: 30 files including three unique RTM tools are deleted — verify their outputs are reproducible elsewhere first. EITHER WAY, resolve the 5 diverge…

S-16. Is the claude CLI a hard requirement of the fresh-machine bootstrap, or an over-restriction the installer should relax?

• Side A. HARD REQUIREMENT. The installer's own comment gives the reason: the orchestrata plugin is the hook delivery path, so a machine without the CLI can never get a wired ~/.claude. On this reading SPEC-108 FR-002 and ERR-001 are stale at five tools and must be amended to six, carrying the reason into the spec so the next reader does not delete it again.
• Side B. OVER-RESTRICTION. The file layer of the deploy works without the CLI and only the plugin sync fails, so the installer could degrade to a warning and let a machine be provisioned before the CLI is installed. On this reading the installer is wrong, not the spec.

What would settle it. Run the preflight on a container that has git, rsync, cmp, uv and python3 but no claude, and record whether anything useful could still have been deployed. SPEC-108 FR-002 already notes that a clean Ubuntu 24.04 container reproduces this path.

Consequence. HARD REQUIREMENT: two spec edits, no behaviour change. OVER-RESTRICTION: the installer changes and so does ordering step 1 of claude-env/README.md's bootstrap — which is itself stale (it still documents the claude-env/global/ bundle deleted 2026-08-14) and would need rewriting in the same pass.

S-17. Round 1 section 6 states '10 recorded; the coordinators resolved 7 by measurement' and names only 3. Should the 7 claimed resolutions be reconstructed and re-verified before the remediation sequence is acted on, or should section 6 be formally superseded by the master register's contradiction rows?

• Side A. RECONSTRUCT AND RE-VERIFY. A count with no command and no output is exactly the defect round 1's own section 7.3 documents four times, and it appears in the section reporting how contradictions were handled. Of the 3 that WERE named and re-examined by this swarm, all 3 turned out to have both proposed sides contradicted by artifacts — which is not a reassuring base rate for the 7 that were closed without a record.
• Side B. SUPERSEDE. The master register already carries 40+ contradiction-class rows, each with its own evidence and verification state, plus five D-NN decision sections. Reconstructing the 7 costs a pass over round-1 domain reports that exist only as agent transcripts, and may simply turn up resolutions that were asserted rather than measured — which is already a known and documented failure mode.

What would settle it. The round-1 domain-coordinator transcripts, if they were retained. If they were not, side A is not executable and side B is forced by default.

Consequence. RECONSTRUCT: costs a transcript pass and delays remediation, but no round-1 conclusion is acted on while resting on an unrecorded resolution. SUPERSEDE: section 6 must be struck or annotated, because leaving '7 resolved by measurement' standing makes a future reader believe seven contradictions were closed with evidence that does not exist.

S-18. Rotate DEEPSEEK_API_KEY only, or also purge the leaked blob from git history with a force-push?

• Side A. Rotate only. The key becomes worthless the moment it is rotated, the repo is PRIVATE (verified via the GitLab API), history stays intact, no coordinated force-push, no risk to the six worktrees / prod checkout / plugin-cache clone that all track this history, and no rewriting of 44 days of commits. Commit d08aaf60's author already framed removal and rotation as two separable decisions.
• Side B. Rotate AND purge. A private repo is not a secret store: the blob is in every clone, every CI runner checkout, the plugin marketplace clone and any future fork, and it also carries GITLAB_TOKEN and OPENROUTER_API_KEY values that were rotated but whose historical values remain a fingerprint of the credential set. Purging is only cheap while the history is small and the collaborator set is one.

What would settle it. Whether this history will ever leave the current trust boundary — additional collaborators, a public mirror, a CI runner outside this host, or an artifact-sharing workflow. If the answer is never, rotation alone closes it. Also: whether any of the four historical values is reused anywhere outside this repo, which only the user can know.

Consequence. Rotate-only leaves four historical credential values permanently readable by anyone who ever gains repo read access; if the trust boundary widens later, purging then is far more expensive and the values will have been exposed in the interval. Purging now costs a coordinated force-push and re-cloning of six worktrees, the prod checkout and the plugin marketplace clone — and a botched rewrite on a…

S-19. How should the 1,276 findings be driven to zero before check_secret_leaks.py is wired: narrow the [name-pattern] rule, or bulk-waive with # gate-ok: reasons?

• Side A. Narrow the rule. 1,211 of 1,276 come from [name-pattern], and the overwhelming majority are Redis/cache key-name f-strings and env-var NAMES that the rule cannot distinguish from values. Requiring a value-shaped literal (not an f-string, not derived from an identifier) removes them mechanically, keeps the tree free of waiver comments, and means a future file inherits the correct behaviour with no author action.
• Side B. Bulk-waive. Waivers are auditable and reversible: each carries a reason a reviewer can read, nothing is silently un-detected, and the rule keeps its current recall so a genuinely name-only leak (a key assigned from a literal in a doc or spec) still fires. Narrowing trades permanent detection loss for a one-time cleanup.

What would settle it. A sample: take 50 random [name-pattern] hits across tests/, specs/ and plans/ (the 879 in non-shipping trees) and count how many would survive a value-shaped-literal requirement. If near zero, narrowing is free. If a meaningful fraction survives, narrowing is deleting real detection and waivers are the honest choice. Nobody has run that sample.

Consequence. Narrowing wrongly permanently blinds the gate to a whole leak shape and the loss is invisible — the gate stays green. Waiving wrongly leaves 1,200+ waiver comments across the tree that decay into noise, and the next author copies a waived pattern. Either way the ordering is fixed: wiring the gate before triage lands it permanently red and trains --no-verify, which is the exact failure 9454e2dc…

S-20. Does RUL-027 forbid production writing DATA into the dev tree, or only production EXECUTING from it?

• Side A. Execution only. Commit f68876cf (2026-08-16) moved WorkingDirectory, EnvironmentFile and ExecStart to the prod tree and its message declares deploy-in-place closed, while deliberately keeping ORCHGRAPH_BACKUP_DIR, StandardOutput and StandardError in the dev tree with a written rationale in the unit itself: 'the script's PROJECT_ROOT-relative default would restart the 14-run retention window in a fresh prod-tree dir; the archive stays where every existing snapshot lives.' On this reading the rep…
• Side B. Any coupling. The ruling's own principle says 'The development tree is never a deployment target. Nothing running there is production', and gates.py:210-213 names the exact hazard as live: 'caching it on _SRC would let prod be re-pointed at the dev tree without the battery ever noticing.' On this reading three of the four violations are real and the 2026-08-16 commit closed half a defect while its message claimed the whole.

What would settle it. The user's intent for RUL-027, which exists nowhere in the record: the ruling text enumerates four execution directives and never addresses data or logs, and history_intel.py why check_prod_tree_separation returns no_loss_on_record. The unit that decides where 9.5 GB of production state lands is not under version control in this repo, so there is no supersession trail to read.

Consequence. Execution-only means the gate needs an explicit data-path exemption and the 9.5 GB stays one git clean -xdf from destruction inside a checkout that a running container can also write to. Any-coupling means the archive must move (a one-time mv plus three literals in two tracked copies, preserving the retention window the rationale was protecting) and the gate's directive list, glob and fingerp…

S-21. Should the workspace bind-mount into the running claude-orchestrata container become read-only?

• Side A. Make it read-only, matching its twin in orchestrata-test. Nothing documented requires write access, the container is five months old and predates RUL-027 by that margin, and today it can delete backups/ (the only copy of the production KG backup), .git, and 36 GB of worktrees. The read-only twin proves the option is understood in this project.
• Side B. Keep it writable. The container is an agent workspace and agents plausibly write — build outputs, scratch files, worktrees. Setting readonly on a RUNNING container with 17 processes may break an active workflow, and since the container is not in infra/, the change is a hand edit with no converge step to restore it or to document why.

What would settle it. What actually runs inside it. incus exec claude-orchestrata -- ps plus an inspection of what those processes write under /workspace would answer it in one command — I deliberately did not exec into it under the read-only mandate. If nothing writes, read-only is free.

Consequence. Leaving it writable keeps a path by which a process in a container can destroy the only production backup and the git object store, with no gate, no ruling and no IaC covering it. Setting it read-only without checking may break a live agent workflow silently — and because the container is absent from infra/, whichever way it is set, the setting is undocumented and will not survive a rebuild.

S-22. Should sentence-transformers remain an unconditional [project].dependencies entry?

• Side A. Keep it unconditional. Its consumer is the local embedding backend, and a deployment that needs local embeddings must have it resident; the two existing guards (the lazy import inside _load_model() and the GIL_UNSAFE_MODULES quarantine) are correct, dated and demonstrably working — measured, zero flipping extensions are mapped in any of the five running production daemons.
• Side B. Move it behind an extra, as tiktoken and the tree-sitter stack already are. It is the one direct declared dependency of 72 probed top-level names that re-enables the GIL, and it is currently installed by default in every venv including prod's — while two benign packages are gated behind extras. Both guards are conventions that nothing enforces: no check fails if the lazy import moves to module scope, and the quarantine list is hand-maintained with no completeness test.

What would settle it. Whether any production code path constructs a local SentenceTransformer embedder. The RAG/semantic-graph configuration for the prod profile answers it; the analysts established only that the import is lazy and that no daemon has it mapped today, which is consistent with either answer.

Consequence. Keeping it unconditional leaves a GIL-flipping extension one refactor away from being imported at module scope in a SPEC-023 free-threaded system, with no mechanism to catch that. Moving it to an extra risks a production import error at first use if a prod path does need local embeddings and the extra is not installed — a failure that would appear only when the embedder is first constructed, not…

S-23. Which tree is the production knowledge graph's code layer supposed to describe — the deployed prod checkout, or the dev working tree?

• Side A. THE PROD CHECKOUT. The graph is consulted by orchestrata-kernel.service and orchestrata-gateway.service, which execute /home/mohamed/prod/orchestrata-ultimate. RUL-027 ('production runs its own checkout, never the development tree') already rules this way for services, and orchestrata-ast-live-sync.service is deployed watching the prod tree. Under this answer, KG-F7's cache-root bug must be fixed and the sync must cover all six AST roots, not just src/ — the daemon watches 868 of the 2,977 modu…
• Side B. THE DEV WORKING TREE. That is what the graph actually contains today: all 2,977 Module nodes carry dev file_paths, and tools.ast_pipeline is 283 lines in the graph and in the dirty worktree against 246 at HEAD and in prod. /code and the context injector are agent-facing tools whose users are editing the dev tree, so describing the tree being edited may be the intended behaviour. Under this answer the prod ast-live-sync unit's watch root is wrong and the unit should leave the prod fleet.

What would settle it. Your ruling on who the graph's primary consumer is. The measurement that informs it: today the graph describes a state that exists in NO commit (uncommitted analyzer edits reached production before they reached git), and there are two writers owning the same Module node ids with different file_path roots and no supersession rule — whichever ran last wins. If KG-F7 is fixed without settling this,…

Consequence. Choosing prod means the graph stops answering questions about uncommitted work in progress — /code deps and the context injector describe what is deployed, not what you are editing. Choosing dev means production services consult a graph describing a tree they do not execute, and a dirty worktree is permanently part of the production oracle. Either is defensible; the current state is neither, and…

S-24. Which database is the authority for the code->requirement traceability layer: operational orchkg under the canonical vocabulary, or semantic memgraph under the retired one?

• Side A. ORCHKG. canonical_schema.py governs it and states verbatim that test linkage uses TESTED_BY (never TESTS) and that TRACES_TO always targets RequirementItem. Fourteen src/ modules read TRACES_TO from it, including the context injector on the live kernel path. It held 6,302 TRACES_TO edges on 2026-07-21. Cost of this answer: the edges must be rebuilt after the requirement corpus is re-keyed (KG-F3), and the writer needs a runner that survives the AST re-derivation that strips the endpoints.
• Side B. MEMGRAPH. It is the database that actually HAS the data — IMPLEMENTS 22,827, TESTS 16,211, HAS_REQUIREMENT 5,312, plus 618 :File nodes that orchkg does not model at all — so it is a different schema, not a mirror. Cost of this answer: every current reader queries the wrong database and the canonical schema must be amended to declare the semantic graph out of its scope.

What would settle it. Your ruling, plus one measurement I deliberately did not take: whether the TEST orchkg graph (10.53.2.10) holds TRACES_TO edges. If it does, the writer works and was simply never re-pointed at prod after the 2026-07-26 migration, and side A costs one command. If it does not, the writer itself is broken and side A costs a debugging session. That single query changes the price of A but not the prin…

Consequence. Under A, the semantic database's roughly 39,000 traceability edges become orphaned duplicates that will drift silently — they already speak a vocabulary the canon retires. Under B, fourteen production modules including the live context injector are pointed at the wrong database and must be rewired, and the canonical schema's authority over traceability ends. Leaving it unsettled is the current st…

S-25. Which register owns the ADR id space — the repo's docs/adr/ (38 decisions) or the wiki decisions register (25, which the graph currently holds)?

• Side A. THE REPO. docs/adr/ is version-controlled, reviewed with the code, and holds 13 decisions the wiki does not. Under this answer the wiki register renumbers and the 25 graph nodes are replaced.
• Side B. THE WIKI. It was deployed into the graph first (2026-07-19), it is what every graph consumer reads today, and per your standing memory the wiki is the canonical ADR register with the repo renumbering +25. Under this answer docs/adr/ renumbers to 0026-0063 and the graph gains the 13 missing decisions under new ids.

What would settle it. Your ruling. The measurement is unambiguous and does not favour either side: all 25 overlapping ids ADR-0001..0025 name DIFFERENT decisions in the two corpora, both registers write the same key {project}:ADR-{number:04d} via the same writer, and the graph holds the wiki decision in all 25 cases. There is also an uncompared fourth surface — 38 :ADR nodes in the semantic database, matching docs/adr…

Consequence. Whichever way it goes, a renumbering breaks every existing citation of the losing register's ids across plans, commits and session history. Not deciding costs more each week: the two registers keep growing into the same key space through the same writer, and the only detector that would report it runs in zero automated contexts.

S-26. Should the 34,506-node ConversationTurn corpus be aged out, archived, or left to grow — and what should happen to the 118 orphan conversations holding 7,150 turns?

• Side A. AGE IT OUT with the other exhaust. It is the largest exhaust label by volume, growing roughly 600 nodes/day, and 47.5% of it is duplicates. Retention would bound the graph and is the same treatment every other exhaust label needs.
• Side B. ARCHIVE, NEVER DELETE. It is the only exhaust label with a real reader — ~/.claude/tools/conversation_recall.py is your sanctioned conversation-history tool — and deleting it deletes the project's conversational memory. Under this answer retention widening (KG-F15) must explicitly exclude it and an archival path is needed instead.

What would settle it. Your ruling on the value of old conversation history. The orphan disposition is a separate call within it: of the 118, five carry pytest test-function names (test_execute_returns_tuple0/1/2) and are unambiguous test pollution to sweep; around 70 are ephemeral claude-cli-adapter-* ids holding 140 turns; and 43 carry real slugs (mohamed, knowledge-wiki, orchestrata-handover, dr-hannah) holding 6,99…

Consequence. Aging it out bounds the graph and closes 5,319 of the 67,665 unreachable nodes, at the cost of history you cannot recover. Archiving keeps the memory but leaves the largest uncovered exhaust label growing indefinitely. Deleting the 43 real orphan conversations wholesale would destroy 6,997 turns; linking them requires minting :Project nodes for slugs like mohamed that are directory basenames, n…

S-27. May a controlled WRITE probe be driven through the deployed gateway to settle whether the kernel/orchestrator graph writers are disconnected or production is simply idle?

• Side A. YES, RUN IT. One real intent through the deployed gateway, checking whether a CXPPacket, Intent, PipelineRun and GatewayAuditEvent appear, is the only measurement that separates the two explanations. If they appear, the finding closes as idleness. If they do not, the entire governance and pipeline audit trail is disconnected in production and that is a FATAL nobody has filed.
• Side B. NO, LEAVE IT READ-ONLY. This analysis pass is mandated read-only, and driving an intent writes to the production graph and the production audit trail. The exhaust silence may be fully explained by the 2026-07-26/27 migration cutover, which is exactly when four of the five silent streams stop.

What would settle it. Your authorisation. What is already measured and is not in dispute: CXPPacket, Intent and PipelineRun all stop at 2026-08-05T09:36:51; GatewayAuditEvent collapses on the same day and has 14 events since (last 2026-08-19); kernel-shaped ToolCall, Run and PolicyDecision stop at 2026-07-26; and both daemons are active 8h at 0 restarts on the prod venv with correct exe and cwd binding. The 2026-08-05…

Consequence. Running it resolves the highest-uncertainty question in this domain in one command, at the cost of a small permanent write to the production graph and audit trail. Not running it leaves the status of five production write paths unknown indefinitely, because nothing else in the exhaust can answer it — and if they ARE disconnected, every day that passes is a day of governance decisions with no audi…

9. What is healthy — 13 claims attacked that survived

Recorded because a report of only defects cannot be checked. Where a control arm exists — a probe proven able to fail — it is stated; absence of evidence is not.

• Deployment byte-integrity survived attack on every surface examined. PROD is git-clean at 143310ec = origin/master (I re-verified: 0 dirty files), all 11 installed unit/timer files are byte-identical to the prod repo's deploy/systemd sources (identical=11, differs=0), ~/.claude's deployed python artifacts differ from version control only by the installer's deliberate shebang rewrite (0 content diffs across 136 files…
• All 5 running production daemons are correctly bound: exe and cwd both resolve into ~/prod/orchestrata-ultimate under the free-threaded uv interpreter (3.14.6, GIL False), ORCHESTRATA_ENV_PROFILE=prod, NRestarts=0, zero DEV-tree memory maps or file descriptors, and no ERROR/CRITICAL/Traceback in the retained journal.
• The test suite's stated purity discipline holds by independent AST measurement, not by assertion: across all 1,782 .py files under tests/ there are 0 mock imports or names, 0 monkeypatch parameters/imports/MonkeyPatch references of any form, 0 @pytest.mark.skip/skipif/xfail decorators, 0 pytest.skip/xfail/importorskip calls, and all 34 os.environ mutations carry # gate-ok: waivers. The scan had a working control a…
• Absolute-import discipline is clean and is backed by a mechanism whose exit code carries the verdict: 0 relative imports across 3,015 files in src/, scripts/, claude/ and tests/, with the same detector returning 2 on a deliberately-bad fixture, enforced by prolog/gate_rules.pl:136 at error severity through scripts/gate.py's 0/1/2 exit contract. This is the structural opposite of the advisory architecture exit code a…
• Behavioural coverage of the named critical subsystems is real: 64 of 77 public defs across kernel dispatch/router/kernel, governance verdict/policy_engine/constitutional, promotion stages/runner and gateway auth have a hand-written value-asserting caller, with 0 covered only by generated tests and 0 whose only coverage comes from never-collected modules. Facade-resolved reachability is 748 of 753 src modules. The 1,…
• The infrastructure env seams are correct where they are used: under env -i, resolve_uri, resolve_kg_database, resolve_redis_host, resolve_redis_port and cxp_grpc_port ALL raise rather than falling back to a literal. RUL-003's no-infra-default rule is right at the seam; the defects are callers that bypass it in roots the detectors do not scan.
• 21 of 23 gates PASS under the project venv in 154.3s wall, and the two failures are honest reds, not false greens: mypy with 14 errors all in src/orchestrata_ultimate/postman/governance.py (I re-confirmed the cache records ok=false for mypy and plugin-drift), and plugin-drift with 2 drifted commands. The prolog-gate, which was failing, now passes.
• Four passing gates declare their blind spots in the same output that reports PASS — external-tools names 80 unchecked non-literal argv[0] sites, prolog-boundary documents its undetectable F3 argument-order class, parallel-safety marks its filesystem warnings advisory, uncovered-policies is advisory by explicit user ruling. That is the correct behaviour and the opposite of the pattern that dominates this report.
• The one cross-authority consistency check in the spec domain holds: docs/adr/README.md's 38 register rows agree with each ADR file's own Status on 37 of 38, with one wording divergence and one format divergence. Contradiction density in this system is not uniform — the repo ADR log is maintained; the spec index, the Status field and the RTM layer are not.
• Stub-method hygiene is clean: of 502 stub bodies across 6,485 class-body methods in src/, 482 are Protocol/ABC/@abstractmethod members and 19 of the 20 residuals are documented no-ops or base contracts. One real exception remains (FactManager.on_request_start, an empty method whose docstring claims it initializes tracking, referenced only from tests).
• check_generated_artifacts' atomic-write DETECTOR is sound in isolation: handed the pre-fix source of gen_codebase_map.py it returns line [262]; handed the current source it returns []. The failure is registry provenance (the entry names a shell wrapper, not the writer), not the analysis.
• The conversation capture pipeline is currently lossless end to end: Redis queue depth 0 and the consumer reports 0 quarantined / 0 failed on every flush. The latent turn-loss risk (TOP-11) has not fired.
• All 23 non-library scripts under .claude/hooks/ ARE registered — the registration rot is confined to the claude/ user surface, which check_wiring's W1 prefix cannot see. The project-surface hook tree is internally consistent.

10. Still unexamined after two rounds

• No full test suite run was performed by any of the six domains. The newest evidence anywhere is reports/run-tests-latest.json: 389 tests, 16 modules, self-declared non-authoritative, at a commit that is not HEAD. No statement in this report claims a pass/fail outcome for the suite as a whole.
• Neither knowledge graph was queried by any domain. orchkg and memgraph node completeness, the Spec/Requirement nodes, the 25 ArchitectureDecision nodes, GatewayAudit/PluginAudit node existence (SPEC-014 FR-024, SPEC-015 FR-023), conversation-turn and CXP-exhaust completeness, and the outputs of enrich_semantic_graph_specs.py / sync_traces_to_graph.py are entirely unmeasured. Corpus-vs-graph drift is unknown, and onl…
• No runtime or coverage-instrumented execution of the system. Every reachability claim is static, so a module reached only through DI, a string registry, getattr dispatch, a plugin entry point or python -m looks unreachable — the refactor/codemod/_daemon_entry.py counter-example (0 importers, live) proves the error rate is nonzero. No gateway RPC was issued, no kernel started, no benchmark run.
• Whether the 25 project PreToolUse guards fire in a top-level interactive session, and whether ~/.claude/settings.hooks.json is read by the harness at all. These two harness-semantics questions gate the interpretation of the entire enforcement domain and could not be answered from inside a delegated session.
• The TEST fleet entirely: the Incus orchestrata-test app container's own systemd units, their EnvironmentFile contents, and whether they declare ORCHESTRATA_ENV_PROFILE=test or inherit the loader's 'test' default. Every measurement in this report is host-side or PROD. Network separation between fleets ('this env cannot reach prod (Incus ACL)') was never tested; only filesystem separation was.
• Requirement CONTENT was never read. All 7,256 requirement texts were graded on ids, files, grammar, registry membership and citation linkage; nobody judged whether any single requirement is correctly implemented. A requirement graded CITED can still be implemented wrongly. No generate_rtm_evidence.py --verify pass was ever run, so the TESTED/FAILING grades — the only ones involving execution — occur nowhere in the…
• 41 of the 47 specs marked Complete/Implemented/Production Ready were never opened (a 12.8% sample), and the divergence rate found must not be extrapolated. Non-functional requirements across every spec examined are entirely unmeasured — no latency, throughput or scale target was benchmarked.
• 21 of the 23 gate scripts were never attacked with a constructed violation; they were run and their verdict lines read. Given that the one gate that WAS attacked that way (prod-separation) turned out to scan 7 of 20 units, the same class is plausible and unmeasured in the other 21. Their own line coverage under their test modules is also unmeasured, so 'has a negative-corpus test' says nothing about how much of each…
• The waiver and exemption surfaces were never audited for growth: 321 live # gate-ok: markers, plans/feature-loss-invalid-citations.json, check_generated_artifacts' 15 declared non-artifacts and 8 prose-generator exemptions, check_external_tools' allowlist, check_lexicon_collisions' 10 exemptions, STORY_EXISTENCE_BASELINE (79 of 80 entries unreachable). A gate defanged by a growing waiver file passes every check in…
• Git history was used by no domain. Nobody dated any defect, so regression-versus-never-finished is unresolved for every disconnection here — including whether the two pre-commit review gates ever worked (which decides whether every historical 'code review passed' claim is void), when --strict-markers became inert, when LAYER_ASSIGNMENTS lost 11 packages, and whether commit e627ba0b was committed with --no-verify.
• deploy/ship.sh, deploy/install-claude-config.sh --verify and scripts/promote_env.py were never executed (read-only mandate). Whether ship's stated 'the running thing IS the deployed thing' step CAN fail is untested — and the platform convention requires exactly a verification step that refuses success. No GitLab pipeline history was read, so whether the live CI actually executes and blocks is unproven.
• Non-Python surfaces were never audited for duplication or correctness: all .sh hooks beyond a handful read in full, .pl rule and ontology files, .md skills/commands/agents, JSON settings beyond named searches, and every TypeScript/JavaScript surface (opencode/, vizint-ui/, end2end/, harness/, features/). The project has no AST-equivalent tool for shell, so a literal endpoint fallback in a .sh file is invisible to ev…
• The knowledge wiki is almost entirely uncovered: of five doc lenses only one read a wiki page (the ADR decisions register), wiki-rag-query was never invoked, no wiki page content was checked against code, and the wiki-side generated pages and their generators were not examined. 17 of the 25 canonical wiki ADRs were never verified against code.
• plans/ (219 markdown files, 485 broken path references) and specs/ (318 files, 176 broken references) were counted mechanically and never triaged; the 63 wide-corpus doc_lint findings were never individually adjudicated, and 30 of them will change once the TEST-COUNT oracle is fixed. About 60% of AGENTS.md's 1,077 lines was skimmed for headings, not verified claim-by-claim.
• The 6 stale worktrees under .claude/worktrees/ and the seventh under .harness/worktrees/ were excluded by mandate — nobody checked whether any owns a deployment or a running process. pycache trees were excluded from every byte comparison, and /opt/orchestrata-tools/.venv package contents (dated 9 days older than the deployed lib, recreated only when the interpreter is absent) were never audited.
• Nobody established that commit 143310ec is itself correct. Every byte-integrity finding proves deployed == pinned; none proves pinned == intended.

11. Method — measurement traps this analysis fell into

Every entry cost a wrong finding at least once. Any later round inherits them.

1. Generated inventories name every module that exists (CODEBASE_MAP*, ast-*.json, rtm.json, facts.pl). A grep hit inside one is not evidence of use.
2. .claude/worktrees/ holds stale checkouts with their own site-packages; including them inflates any repo-wide count several-fold.
3. Stem-matching module names conflates unrelated files (models.py matched 295 importers). Use exact dotted paths.
4. A proof run against seeded state is not a claim about production state.
5. A fix must be prescribed against the line that executes, not the line that looks authoritative.
6. Success asserted against the wrong oracle: a batch that matches zero rows increments a counter by zero and is logged OK.
7. git status cannot see gitignored writes; verify read-only mandates with find -newermt.
8. Generated artifacts move mid-analysis — orchestrata-ast-live-sync.service rewrote all four AST snapshots at 09:16 during round 1. Hash the snapshot before and after.
9. grep on binary files prints nothing whether the answer is 'absent' or 'could not read'. Use grep -a, or an in-process byte count.
10. A generated artifact's documented regeneration command may not reproduce it. Read the artifact's own provenance fields (root_path, extra_roots) and check for post-merge passes first — plans/ast-ultimate.json loses 70% of its modules and every runtime_calls edge to its own documented command.
11. Absence of evidence inside a bounded observation window is not evidence of absence. Three tools reported nothing about claude/ because all three are structurally blind to it; the correct conclusion was 'my instruments cannot see', not 'it never existed'.
12. A resumed workflow appends re-run results beside the originals, so one agent slot appears twice with different content. Deduplicate on the assigned lens key — agent-authored lens/domain prose drifts between a run and its re-run and cannot be keyed on.

Related

• Plans
• Orchestrata Ultimate — project index
• Workflow
• Tasks