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

I2664

A run that has already failed is cancelled by itself, and a red on the trunk is fixed before anything else is prepared

Where it stands

devtask.issue

Readiness: complete completion is recorded and every required evidence token is present
Status: DONE
Can start: not now
Milestone: M004
Milestone status: ACTIVE
Wave: 0
Waiting on: none
Holds back: I2709
Behind it in all: 1
Evidence: 2 of 2

Moves

plan.transition

What it is

Objective: Make the time from a red to its fix the thing the pipeline is built for: a run stops spending runners the moment it cannot be green, and the trunk's red has one carrier at once.
Why: The owner, 2026-10-13: 'keep fixing red jobs as they appear, cancel early failed pipelines at once, to be more efficient; make it an ADR, knowledge, rule, enforced through .ai; it must not happen again; turnaround speed is king.' That evening a validate run with two failed jobs kept nine more jobs running for twenty minutes while a deployment and a release waited for runners, and its failing log could not be read until it ended.
Now: Measured 2026-10-13 on validate 38470127001 (master a3a67a307e): the pages job failed at 22:1x and rust (3) at 22:20Z; nine jobs ran on until the run was cancelled by hand at 22:23Z, and the log of the failed job was refused while the run was in progress. The failure was a crate test (tests/skills.rs requires every active skill to be named in its header) broken by a pull request merged with --admin whose lander had run the structure job and no rust lane. ADR 0155 clause 7 lets a lander cancel only its own branch's run, and nothing cancels a run that can no longer pass.
Wanted: The validate workflow ends a run at its first failed job unless the run is the trunk's and asked to finish for diagnosis; a failed job's log is read through the jobs API without waiting for the run. A lander's verdict before an --admin merge includes the crate's tests whenever the change adds or changes a record a crate test reads, and the gate that knows which records those are names them. A red on the trunk is announced with its carrier, and no landing is prepared on top of it until the fix is merged.
Done when: unknown: the record declares no `completion`
Risk: unknown: the record declares no `risk`

Acceptance

A validate run on a branch is cancelled by the workflow itself when one of its jobs has failed, and a case holds the workflow to it
The rule of expedited landings says which jobs a lander reads for which kind of change, and names the crate tests that read repository records (skills, rules, claims) as part of a record change
Adding an active skill without naming it where the crate test requires is refused by a structure gate, not first by a rust lane an hour later

Validation: bin/majordomus plan validatescripts/ci/github-checkscripts/ci-plan --check
Evidence required: a_failed_run_is_cancelled_caseskill_named_by_crate_test_gate
Evidence present: a_failed_run_is_cancelled_caseskill_named_by_crate_test_gate

Scope

Touches: .github/workflows/validate.ymlscripts/ci-plan.ai/repo/rules/project/an-expedited-landing-is-the-owners-word.v1.md.ai/repo/adrs/0155-an-expedited-landing-is-the-owners-word.mddocs/INTEGRATION.mddocs/CI.md.ai/repo/project/issues/I2664.yaml
Not: Buying runnersPublishing by artifact, which is I2660, and the runner bound of validation, which is I2662
Depends on: none
Priority: p1
Profile: implementation
Parallel safe: true
Owner: unknown: the record declares no `owner`

The work so far

Branches: none
Merged: none
Commits: 0
Trunk: master
Sessions: none
Created: 2026-10-13
Updated: 2026-10-14T12:55:14Z
Started: 2026-10-14T12:55:10Z
Verified: unknown: the record declares no `verified_at`
Completed: 2026-10-14T12:55:14Z

Synchronisation

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

Findings

Nothing is wrong with these records.