A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I1404

The drift check is a gate, so a projection that stops being applied cannot stay silent

Where it stands

Readiness: complete completion is recorded and every required evidence token is present
Status: DONE
Can start: not now
Milestone: work-graph-github
Milestone status: VERIFY
Wave: 2
Waiting on: none
Holds back: I1403 I1407 I1408
Behind it in all: 3
Evidence: 2 of 1

Objective: Run `scripts/github-sync --check` from CI on every change that can move the canonical model or the adapter, and fail the build on drift with the record and the remedy named.
Why: This is the root cause of the milestone. The adapter has exited 11 on drift since it was written and nothing has ever called it, so the projection decayed from complete to 10 per cent without one red build. `core-check` runs --plan and --render, which prove the adapter runs, not that the projection is current.
Now: scripts/ci/core-check lines 67 and 69 run --plan and --render. .ai/repo/ci/gates.yaml line 178 already lists scripts/github-sync in the paths that trigger the core gate, so the trigger exists and the check does not.
Wanted: A drift finding is a build failure. The gate needs a token to read the remote, so it declares what it needs and says so when it is absent rather than passing quietly.
Done when: unknown: the record declares no `completion`
Risk: Wiring a zero-tolerance gate before the backfill would make master red on a backlog nobody introduced today. The two tolerances are the mitigation: the states that mean new drift are refused from the first run, and the backlog is ratcheted against a committed baseline that may only fall. That inverts the dependency — the gate no longer waits for I1403, and I1403 becomes the act that lowers the baseline to zero.

The gate runs the drift check on every change to the model or the adapter, refuses behind, edited, conflict, unmanaged, state and milestone outright, and ratchets missing and adopt against a committed baseline
A missing or unauthorised token is reported as an unusable gate, never as a passing one
A rule states that the projection is gated, and doctor verifies the gate is wired rather than merely present
Introducing a canonical issue without projecting it turns the gate red, proved by a case
Moving a canonical record that was already projected turns the gate red, proved by a case
The baseline may fall and may never rise, and the gate refuses to run without one

Touches: scripts/ci.ai/repo/ci/gates.yaml.github/workflows.ai/repo/rules/projecttest/cases
Not: Applying the projection from CI, which stays a deliberate human act
Depends on: I1402
Priority: p0
Profile: implementation
Parallel safe: false
Owner: unknown: the record declares no `owner`

Adapter: scripts/github-sync
Repository: unknown: the derived plan's header carries no repository
External issue: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Nothing is wrong with these records.