Repository navigation
skills: vendor lead-orchestrator 2.0 and break-test's parallel-shell lesson (ADR-0190) - #438
Merged
Merged
Conversation
…lesson (ADR-0190) what changed fetchproof/skills/lead-orchestrator/ is version 2.0, the owner's claude.ai account copy of 2026-10-04, in place of SkillsMDs 3f2d2fc's 1.x: SKILL.md and six references (agent-briefs, careful-execution, changelog, project-facts-template, report-templates, run-ledger), with ADR-0186's spelling map and nothing else changed; four files carry a dated Apache-2.0 4(b) marker, three are byte-identical to the account copy. 2.0's own integration reference is not shipped: the kit's references/fetchproof.md stays, its header says why, and its section 4 says the templates ship and the project's conventions come first. auto-build's ledger pointer names lead-orchestrator's references/run-ledger.md again. break-test's section 0 item 4 ends with the account copy's sentence that parallel shell calls share one working directory, and probe-recipes.md takes its row before "Fix step 6". ADR-0190 amends ADR-0146 decision 3 (status line, index rows 0146 and 0190); CHANGELOG, REUSE.toml (lead-orchestrator gets its own Apache-2.0 annotation, seven files), NOTICE and docs/ARCHITECTURE.md's skill-set line say so. skill-set.test.mjs gains a test that every references/*.md a shipped skill names is shipped where it says; the README count is 2118. why The owner's order of 2026-10-22, from the review of the account's skills. The vendored auto-build was written against 2.0: it runs lead-orchestrator's Phase R, keeps its stage table in RUN.md, asks for the status-words block and writes the PR body from references/report-templates.md; 1.x has none of them, so those pointers led nowhere. The integration reference is left out because it restates the protocol and has drifted (step 9 is brief.mjs alone, against ADR-0138/0150; a collector "holds the key", against ADR-0095). what you verified verified: red-first, the new test on an export of 253f8f4 fails with 8 dangling names (lead-orchestrator's two templates, auto-build's report-templates.md); on the branch it passes. verified: selftest skill-set repo-hygiene architecture-map bundle, 62 passed, 0 failed. verified: root preflight PASS, 0 blocking, 1 warning, 28 passing; root handoff, release evidence examples 6/6, conformance vectors, bundle and decision-project preflights exit 0; working tree LF; git diff --cached --check clean. verified: each shipped lead-orchestrator file equals the sha256-recorded account file after the rename and its marker; both break-test files equal the renamed account copy apart from their markers. verified: on this PC the recorded skillSetHashes equal the deployed SKILL.md for lead-orchestrator, break-test and auto-build, so the next install.mjs replaces them; a changed deployed copy stays a skillConflict. expected: the commit gate runs the full suite, since fetchproof/ is staged (ADR-0120). untested: an agent run of 2.0 inside a Fetchproof project. what you got wrong mistake: ADR-0190's draft gave 1.x as three files and 629 lines, said REUSE.toml added the new references to the SkillsMDs annotation, and break-test's markers called the account copy "later" than SkillsMDs; NOTICE said the rename changed "five more" files where its list names six. where: docs/adr/0190-..., Context and decision 5; the two break-test markers; NOTICE; before the commit. impact: none delivered; a reader would have miscounted 1.x and the renamed files, looked for the files in the wrong REUSE block and dated the lesson after the receipt. cause: I wrote from my notes, not from 84d3861, REUSE.toml, the account copy's date (2026-10-03, before the 2026-10-06 receipt) and the list the count sits beside. fix: two files, 569 lines; an annotation of its own with seven files; "the account copy of 2026-10-03, which has it and SkillsMDs does not"; "six more". verified: wc -l on 84d3861's two files, REUSE.toml re-read, the backup's metadata date, NOTICE's list counted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e resume order (ADR-0190) what changed lead-orchestrator's references/fetchproof.md: section 1 (Readiness) says where research goes in a Fetchproof project (the project's own research/, one question per project, a new project via new-project.mjs where the project's rules place one, ADR-0030), and section 2 says that a session continuing earlier work reads where the project stands first (resume-from-disk, then the router), and that Phase R resumes only an existing run folder. ADR-0190 decision 2 records both. skill-set.test.mjs pins them; the README count is 2119. why The fresh-eyes review of e36bc72 found two low gaps. 2.0's Phase 0 reads the research folder convention from the note's "Readiness", which did not hold it (2.0's unshipped integration reference did). And 2.0's description now triggers on "continue" and "resume", as resume-from-disk does, while Phase R starts a fresh run when no run folder exists. what you verified verified: red-first, the new test on an export of e36bc72 fails (17 passed, 1 failed); on the branch skill-set passes 18 of 18. verified: selftest skill-set repo-hygiene architecture-map, 51 passed, 0 failed; git diff --check clean. expected: the commit gate runs the full suite (ADR-0120). untested: which skill a runtime loads when both descriptions match "continue"; the note now says which comes first either way. what you got wrong mistake: e36bc72 checked that 2.0's pointers into the kit note resolve by section name, not that the sections hold what 2.0 sends readers there for; and the first draft of the section 2 sentence credited AGENTS.md with naming resume-from-disk and the router, which it does not. where: ADR-0190 decision 2; references/fetchproof.md section 2, before staging. impact: none in a release; a lead in Phase 0 would have found no research folder convention, and a bare "continue" could have opened a fresh run. cause: I checked headings, not contents. fix: section 1 and section 2 text, the ADR bullets and a pin test; the sentence now credits AGENTS.md only with reading from disk first. verified: the new test red on e36bc72, green here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
SKILL.mdplus six references (agent-briefs,careful-execution,changelog,project-facts-template,report-templates,run-ledger).references/fetchproof.mdstill governs. 2.0's own integration reference is not shipped, because it has drifted from ADR-0095, ADR-0138 and ADR-0150.references/run-ledger.mdagain.probe-recipes.md.references/*.mda shipped skill names is actually shipped; it fails on main. A second test pins the kit note's answers.Why
The vendored auto-build was written against 2.0. It names Phase R,
RUN.md, the status-words block andreport-templates.md, and 1.x has none of them, so those pointers led nowhere.Verified
After merge
node fetchproof/bin/install.mjsreplaces the deployed lead-orchestrator, break-test and auto-build. A deployedSKILL.mdthat a user changed is kept and listed as a conflict.