I1999 — A tracked file a hook regenerates does not refuse a task that never touched it
Let a repository declare the tracked paths its own tooling rewrites, have `check` and `finish` judge them as the machine's and not the worker's, and make the scope finding and the note finding say what settles them before `finish` refuses.
READY wave 0 · p2 · implementation profile · parallel safe
Ready. Every dependency is done, so majordomus plan start I1999 will be accepted.
Objective
Let a repository declare the tracked paths its own tooling rewrites, have `check` and `finish` judge them as the machine's and not the worker's, and make the scope finding and the note finding say what settles them before `finish` refuses.
Why
Reported by an adopter session (progresus-isir) on 2026-10-08 with majordomus 0.14.0: seven tracked files are rewritten by a post-checkout hook on every checkout, so every task showed them as changed outside its scope and `check` failed on work that never touched them. The interim advice — name the seven files in --scope — was measured to work: 0 failing in `check` over three tasks and two `finish --outcome completed` (t-20261008121807-0d62, t-20261008123637-b728). Two things still tripped the adopter. `finish` also refused on majordomus.note-integrity while `check` had shown the note line only as INFO, so nothing said a handover had to exist first. And the scope finding gives no pointer to a remedy: 'restore the file' is not one where a hook rewrites it at once.
Current state
The scope check treats every changed tracked path alike. A path a hook regenerates must be named in each task's --scope by hand. The scope finding names the path and nothing that settles it. `check` reports a missing completion note as INFO and `finish` refuses on it.
Desired state
A repository declares its machine-regenerated tracked paths once, with the reason, and the scope check reports a change to one of them as the machine's: named, not failing, and not silently dropped. A scope finding on any other path says the two remedies — name the path in the scope, or stop tracking the file — and does not advise restoring a file the repository declares regenerated. `check` reports what `finish` will refuse over a note or a handover with the same severity `finish` uses, and names the command that writes it.
Scope
- bin/majordomus
- lib
- apps/majordomus-cli/src
- share/skeleton
- docs/CLI.md
- docs/ADOPTION.md
- test/cases
Dependencies
None. This issue is a root of the graph.
Acceptance criteria
- A repository that declares a regenerated path passes `check` on a task whose scope does not name it, and the report names the path and the declaration that covers it
- A change to an undeclared path outside the scope still fails `check`, and the finding names both remedies
- A declaration without a reason is refused
- Whatever `finish --outcome completed` refuses over a note or a handover, `check` reports as failing beforehand with the command that settles it
- The shell tool and the Rust executable give the same verdict for the same tree
Validation
- bin/majordomus plan validate
- MJ_TEST_JOBS=4 bash test/run.sh <the case this issue adds>
Evidence required
- regenerated_paths_scope_case
- check_reports_what_finish_refuses_case
Evidence
None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.
Timeline
- started
- —
- verified
- —
- completed
- —
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I1999.yaml. Read it back with majordomus plan show I1999.