amsd-pipeline-shared 0.5.41 → 0.5.43

package/docs/gateway-baseline-2.0.80.md5

@@ -225,6 +225,7 @@ f64fdd6bc6df7e13d742e9e53a470be4  scripts/lib/release-lines.sh
 1cc1978d614fca875ad1117e9ac42f93  scripts/lib/render-engine-prompt.sh
 6894e248c7a86d07626b7e981d534354  scripts/lib/render-prompt-section.js
 9768775dcd035b39932f3ebce243857e  scripts/lib/resume-semantics.sh
+c2761c77c580a4f7c5bc36d6dfe797cf  scripts/lib/roster-seams.js
 9216939efdf63c244d42d91ba6fb466c  scripts/lib/run-checkpoint.sh
 886860d643c5db8fb3bfcf5bd3efaf9d  scripts/lib/run-modes.sh
 912511e457b0a6f4801c479400b1c3a3  scripts/lib/seam-invocation.js

package/docs/gateway-files.txt

@@ -233,6 +233,7 @@ scripts/lib/model-ladders.sh
 scripts/lib/orchestration-resume.sh
 scripts/lib/phase-exit.sh
 scripts/lib/pipeline-commit.sh
+scripts/lib/pipeline-tools-mcp.js
 scripts/lib/pipeline-tools.js
 scripts/lib/plan-hash.js
 scripts/lib/plan-of-record.sh
@@ -252,6 +253,8 @@ scripts/lib/release-lines.sh
 scripts/lib/render-engine-prompt.sh
 scripts/lib/render-prompt-section.js
 scripts/lib/resume-semantics.sh
+scripts/lib/roster-mint-cycle.js
+scripts/lib/roster-seams.js
 scripts/lib/reviewer-model.js
 scripts/lib/run-checkpoint.sh
 scripts/lib/run-modes.sh

package/orchestrations/prompts/templates/agent-proposal.json

@@ -24,9 +24,10 @@
     "'implementer'; a CORRECT, investigator-rich survey made it label everything 'investigator'.",
     "Improving the survey made the roster worse.",
     "2026-08-17: the name rule said 'ending in \"-engineer\" or \"-specialist\"'. The invocation registry has twenty name-shape rules and `specialist` is in none of them, so every name of that shape threw at resolveSeam and killed the run at mint — a coin flip on the model's wording. The rule is now __NAME_RULE__, derived from the registry's own seamPatterns, so the mint can only be offered a shape that routes. The examples above lost their suffix for the same reason: they were a fourth copy of the same fact.",
-    "v2 (operator, 2026-10-24: the roster minted for AMSD-2974 named every agent after the ticket's subject (<codeline>-toast-detective, toast-accessibility-engineer) and its briefs described that one ticket; the roster and its prompts are cached per codeline and reused for every later story, so the next ticket on these codelines would inherit them). A role is the codeline's, for every story it will ever be given."
+    "v2 (operator, 2026-10-24: the roster minted for AMSD-2974 named every agent after the ticket's subject (<codeline>-toast-detective, toast-accessibility-engineer) and its briefs described that one ticket; the roster and its prompts are cached per codeline and reused for every later story, so the next ticket on these codelines would inherit them). A role is the codeline's, for every story it will ever be given.",
+    "v3 (operator, 2026-10-24: \"The purpose of re caching was to remove user story references in profiles and prompts\" — zero, not \"zero except marked examples\"): the sets are kept per codeline and reused for every later story; any reference to the ticket in scope, however labelled, is inherited by the next story's agents. Run 14's fresh mint had codeline-level names and briefs of seven \"worked example: for AMSD-2974 …\" sentences each, approved under the earlier wording."
   ],
-  "body": "You are a senior engineering manager designing an AI agent team for a software project.\n\nThe following __FIXED_ROLE_COUNT__ fixed roles are ALWAYS present and must NOT be reproduced:\n__FIXED_ROLE_LIST__\n\nGiven the project manifest, tech stack, and clarification answers, propose 2-6 project-specific engineering agent roles that will implement the user stories. Each role should map to a distinct domain of the project — one per domain, e.g. a react-frontend role, a postgres-data role, an auth-security role. The exact name shape is fixed below.\n\nEvery role is one of TWO KINDS, and you must state which:\n\n- \"implementer\" — WRITES the change. This is the role that edits source and makes the work\n  happen. An implementer spans the project, so its codeline is \"*\".\n- \"investigator\" — READS one codeline and characterises what is there for the implementer. It\n  never writes. An investigator names exactly ONE codeline, spelled as listed in scope.\n\nYOU MUST PROPOSE AT LEAST ONE IMPLEMENTER. A team of investigators can describe the work and\ncannot do it: every story is assigned to an implementer, so a roster without one leaves every\nstory with nobody to write it and the run cannot proceed. Investigators are optional and\nadditive — propose them where a codeline genuinely needs its own reader.\n\nThe survey above recommends both: which codelines need investigating, and which need work\nwritten. Those are recommendations about the team, not instructions — you decide the roster.\n\nFor each role provide:\n__NAME_RULE__\n- kind: exactly \"implementer\" or \"investigator\"\n- codeline: for an investigator, the ONE codeline it reads; for an implementer, \"*\"\n- systemPrompt: A detailed system prompt (150-300 words) describing the agent's expertise, the project's conventions, key files/directories they own, coding patterns they follow, and tools they use. Be specific to this project.\n- rationale: One sentence explaining why THIS project needs THIS role. It is read by a human\n  reviewing the team and seeds the agent's knowledge base, so it must say something.\n\nRespond with ONLY valid JSON (no markdown fences):\n{\n  \"proposedAgents\": [\n    { \"name\": \"<string>\", \"kind\": \"<implementer|investigator>\", \"codeline\": \"<name or *>\", \"systemPrompt\": \"<string>\", \"rationale\": \"<string>\" }\n  ]\n}\n\nA ROLE OUTLIVES THE TICKET. The roster is kept with its codeline and reused for every story that codeline is given later, so each\nrole is minted for the codeline's work, not for the work in scope now: its name says what kind of engineer or investigator it is and\nwhich codeline it serves, never the subject, component or ticket of the current story; its system prompt describes the codeline — its\nstack, conventions, surfaces and how to verify there — and the kind of work the role does, and names the current ticket's subject,\ncomponents or files only as examples marked as such. A role that only makes sense for the story in scope is a defect.\n",
+  "body": "You are a senior engineering manager designing an AI agent team for a software project.\n\nThe following __FIXED_ROLE_COUNT__ fixed roles are ALWAYS present and must NOT be reproduced:\n__FIXED_ROLE_LIST__\n\nGiven the project manifest, tech stack, and clarification answers, propose 2-6 project-specific engineering agent roles that will implement the user stories. Each role should map to a distinct domain of the project — one per domain, e.g. a react-frontend role, a postgres-data role, an auth-security role. The exact name shape is fixed below.\n\nEvery role is one of TWO KINDS, and you must state which:\n\n- \"implementer\" — WRITES the change. This is the role that edits source and makes the work\n  happen. An implementer spans the project, so its codeline is \"*\".\n- \"investigator\" — READS one codeline and characterises what is there for the implementer. It\n  never writes. An investigator names exactly ONE codeline, spelled as listed in scope.\n\nYOU MUST PROPOSE AT LEAST ONE IMPLEMENTER. A team of investigators can describe the work and\ncannot do it: every story is assigned to an implementer, so a roster without one leaves every\nstory with nobody to write it and the run cannot proceed. Investigators are optional and\nadditive — propose them where a codeline genuinely needs its own reader.\n\nThe survey above recommends both: which codelines need investigating, and which need work\nwritten. Those are recommendations about the team, not instructions — you decide the roster.\n\nFor each role provide:\n__NAME_RULE__\n- kind: exactly \"implementer\" or \"investigator\"\n- codeline: for an investigator, the ONE codeline it reads; for an implementer, \"*\"\n- systemPrompt: A detailed system prompt (150-300 words) describing the agent's expertise, the project's conventions, key files/directories they own, coding patterns they follow, and tools they use. Be specific to this project.\n- rationale: One sentence explaining why THIS project needs THIS role. It is read by a human\n  reviewing the team and seeds the agent's knowledge base, so it must say something.\n\nRespond with ONLY valid JSON (no markdown fences):\n{\n  \"proposedAgents\": [\n    { \"name\": \"<string>\", \"kind\": \"<implementer|investigator>\", \"codeline\": \"<name or *>\", \"systemPrompt\": \"<string>\", \"rationale\": \"<string>\" }\n  ]\n}\n\nA ROLE OUTLIVES THE TICKET — ZERO REFERENCES TO THE TICKET IN SCOPE. This is kept with the codeline and reused for every later story on it, so it refers to no\nticket at all — not the key, title, subject, components, requirements or files of the story in scope, not even as an example. Examples\ncome from the codeline itself: its structure, conventions, manifests and how to verify there. Anything that could only have been written\nwith this ticket in view is a defect.\nA role's name says what kind of engineer or investigator it is and which codeline it serves; its system prompt describes the codeline\nand the kind of work the role does.",
   "description": "Phase B of scaffolding: propose this project's own engineering agent roles. THE MINT PROMPT.",
   "id": "agent-proposal",
   "placeholders": [
@@ -34,7 +35,7 @@
     "__FIXED_ROLE_LIST__",
     "__NAME_RULE__"
   ],
-  "version": 2,
+  "version": 3,
   "seams": [
     "agent-mint"
   ]

package/orchestrations/prompts/templates/prompt-review.json

@@ -20,7 +20,8 @@
     "prose rewrites prompts that were correct, and the placeholder contract already covers",
     "structure. Only a claim that can be checked against the repository is in scope.",
     "2026-10-06, AMSD-2974: metrolinx's repro-test-writer was generated as \"write a spec file for a Toast component at cx-shared\" — the generator completed sentences its slots complete at run time, using the one ticket it was shown, and the reviewer passed it because every claim was true. The prompt serves every story and call; a slot's place is the pipeline's; narrowing and a displaced slot are findings.",
-    "v4 (operator, 2026-10-24: gear each prompt to its use case — strip what is not needed, add net new): the generator may now leave out a segment that cannot apply to this project and add guidance the template lacks (project-prompt-contract.js); the reviewer is shown both (__USE_CASE_EDITS__) and judges them as it judges every other claim."
+    "v4 (operator, 2026-10-24: gear each prompt to its use case — strip what is not needed, add net new): the generator may now leave out a segment that cannot apply to this project and add guidance the template lacks (project-prompt-contract.js); the reviewer is shown both (__USE_CASE_EDITS__) and judges them as it judges every other claim.",
+    "v5 (operator, 2026-10-24: \"The purpose of re caching was to remove user story references in profiles and prompts\" — zero, not \"zero except marked examples\"): the sets are kept per codeline and reused for every later story; any reference to the ticket in scope, however labelled, is inherited by the next story's agents. Run 14's fresh mint had codeline-level names and briefs of seven \"worked example: for AMSD-2974 …\" sentences each, approved under the earlier wording."
   ],
   "description": "Falsifies what a generated project prompt claims about this project, before any agent inherits it.",
   "seams": [
@@ -28,8 +29,8 @@
   ],
   "consumer": "engine",
   "id": "prompt-review",
-  "version": 4,
-  "body": "You are reviewing a PROJECT PROMPT that was generated by specialising a generic template for this specific project. Another agent will receive it as its system prompt and act on every claim in it.\n\nTHE GENERIC TEMPLATE IT WAS DERIVED FROM:\n__TEMPLATE_BODY__\n\nTHE GENERATED PROJECT PROMPT UNDER REVIEW (id: __PROMPT_ID__):\n__GENERATED_BODY__\n\nWHAT THE GENERATOR LEFT OUT OF THE TEMPLATE FOR THIS PROJECT, AND WHAT IT ADDED:\n__USE_CASE_EDITS__\n\nTHE CODELINES THIS PROJECT WORKS ON, and what each one declares:\n__CODELINE_BLOCK__\n\nTHE WORK THE PROJECT WAS ASKED TO DO:\n__TICKET_BLOCK__\n\n__TOOL_LINE__\n\n# What is in scope\n\nTHREE QUESTIONS ONLY:\n1. Does the generated prompt state anything about this project that is FALSE?\n2. Is the generated prompt NARROWED TO ONE STORY OR CALL, or does a slot NO LONGER FIT ITS SENTENCE? (See \"A prompt narrowed to one call\" below.)\n3. Was any part of the template LEFT OUT although it applies to this project, or was anything ADDED that is false of this project or serves only one story or call? A part left out is a finding when its reason is false of the codelines or the kind of project; quote the template's words that were left out as the claim.\n\nA claim is in scope when it can be checked against a repository — a path, a file, a directory, a dependency, a command, a framework, a convention, a symbol, an ownership statement ('X owns Y'). Open the codelines and check it.\n\nExamples of a finding:\n- it names a test directory, file suffix or framework this codeline does not use\n- it names a dependency, script or command the manifest does not declare\n- it asserts a file, module or symbol exists that does not\n- it attributes behaviour to a file that does not contain it\n- it describes a codeline this project does not have, or confuses two that it does\n- it instructs the agent to run something this codeline cannot run\n\n# A prompt narrowed to one call\n\nThe generated prompt is not written for the ticket in scope now. It is reused for every story and every call this project makes to the agent, and each call's specifics — the role for the turn, the file to write, the command to run, the diff, the story — arrive through the slots (the SCREAMING_SNAKE tokens between double underscores) at run time. Compare it with the template, slot by slot, and report as a finding:\n- a statement true only for one story or one call — this ticket's component, a file or path one story will write, a command aimed at one story's file — written where the template leaves that to a slot. It is a finding even when it is true today: the next story receives it as an instruction.\n- a slot that no longer fits its sentence: in the template the slot completes or sits inside a sentence; in the generated prompt the words around it were moved, completed by hand, or rewritten, so the run-time value would land in the wrong place or be said twice. Quote the template's words around that slot and the generated prompt's.\nFor these findings `claim` quotes the generated text, `checked` names the template slot you compared it with, and `found` says what the template has there. Give no `verification` field: this is read from the two texts, not from the repository.\n\n# Before you call anything absent: SEARCH for it\n\nA path in a generated prompt is frequently ABBREVIATED rather than wrong. Looking at the literal\nstring, finding nothing there, and reporting a false claim is the single most common way this\nreview does damage — it rejects a prompt that was RIGHT about the project, the generator rewrites\nthe whole thing to escape a finding that was not real, and in rewriting it drops the placeholders\nthe pipeline depends on. Three attempts of that aborts the run.\n\nSo, for every path, file, directory or symbol the prompt names:\n\n1. SEARCH the codeline for it by BASENAME before concluding it does not exist. `src/routes/checkouts/[checkoutId].ts`\n   and `src/pages/api/checkouts/[checkoutId].ts` are both a SHORTENED form of\n   `src/pages/api/v1/ecommerce/checkouts/[checkoutId].ts`, which exists — that is a near-miss path,\n   NOT a false claim, and it is not a finding.\n2. An IMPRECISE path that RESOLVES to a real file is not a finding. Neither is a partial path, a\n   path missing intermediate directories, or a file named without its directory.\n   A NAME MAY BE A DIRECTORY. A file glob such as **/Name* matches files, not directories, and a\n   text search matches contents, not folder names — neither can show you a directory. Before you\n   call a component, module or folder absent, list its parent directory and look for it there.\n3. Report it ONLY when the thing genuinely does not exist anywhere in the codeline — no file of\n   that name, no such dependency in the manifest, no such symbol in the sources.\n\nAbsence at one exact path is not absence from the repository. If you did not search, you do not\nknow, and \"I did not find it where the prompt said\" is not a finding you may report.\n\n# What is NOT in scope\n\nDo not review wording, tone, length, structure or ambition. Do not propose improvements. Do not object that the prompt is too close to, or too far from, the template — how far it may diverge is decided elsewhere, and the placeholder contract is already enforced mechanically. (A prompt narrowed to one call, or a slot that no longer fits its sentence, is not a question of distance — report it as above.)\n\nA prompt that says nothing false and serves every call is SOUND, however plain it is.\n\n# Evidence\n\nReturn every defect you can evidence, and nothing you cannot. For each finding, say what you CHECKED and what you FOUND, naming the file or manifest you read. A finding without a check is an opinion, and an opinion about a prompt is not a defect.\n\nWhere a finding turns on whether a named path or dependency is present, fill in the verification field as well as the prose. The pipeline re-runs that exact check against the repository and DISCARDS any finding the check refutes — so a careless reading costs nothing, and a correct one is confirmed independently of how convincingly you argued it.\n\nIf every claim checks out, return no findings. An empty finding list from a review that RAN is the correct answer for a sound prompt.\n\n# How to return the verdict\n\nEmit the verdict INLINE as the last thing you write, wrapped in these exact tags. Do not write it\nto a file, and do not use a tool to deliver it — a verdict delivered any other way is not read, and\nthe prompt is then installed unreviewed.\n\n<PROMPT_REVIEW>\n{\"falseClaims\": []}\n</PROMPT_REVIEW>\n\n`falseClaims` is a list of the defects you evidenced. Each entry is an object:\n\n- `claim`       — the false statement, quoted from the generated prompt\n- `checked`     — what you opened or ran to test it, naming the file or manifest\n- `found`       — what was actually there\n- `verification` — when the finding turns on a named path or dependency being present or absent,\n                  an object stating what to re-check, so the pipeline can confirm it independently\n\nTHE ROLES THIS PROJECT MINTED, which is the ground truth for any claim naming an agent:\n\n__ROSTER_BLOCK__\n\nA prompt naming one of these is stating a FACT, not inventing one. Check the list before calling a\nrole false — an unverifiable claim is not a false claim, and rejecting one costs a regeneration and\nteaches the generator nothing.\n\nTHE BLOCK IS THE WHOLE ANSWER. Nothing you write outside it is read — the consumer matches the\ntags and discards everything else. Do not narrate your investigation, do not summarise what you\nchecked, and do not restate the prompt back. Put your evidence INSIDE `checked` and `found` on the\nfinding it belongs to, where it is kept; anywhere else it is thrown away.\n\nMeasured 2026-08-27: reviews averaged 3,366 output tokens to deliver a 13-token verdict. Every one\nof those tokens was billed and 99% of them were discarded unread.\n\nAn empty list is the correct verdict for a sound prompt. Emit the block either way: the block is\nhow a review that RAN is distinguished from one that did not run at all.\n",
+  "version": 5,
+  "body": "You are reviewing a PROJECT PROMPT that was generated by specialising a generic template for this specific project. Another agent will receive it as its system prompt and act on every claim in it.\n\nTHE GENERIC TEMPLATE IT WAS DERIVED FROM:\n__TEMPLATE_BODY__\n\nTHE GENERATED PROJECT PROMPT UNDER REVIEW (id: __PROMPT_ID__):\n__GENERATED_BODY__\n\nWHAT THE GENERATOR LEFT OUT OF THE TEMPLATE FOR THIS PROJECT, AND WHAT IT ADDED:\n__USE_CASE_EDITS__\n\nTHE CODELINES THIS PROJECT WORKS ON, and what each one declares:\n__CODELINE_BLOCK__\n\nTHE WORK THE PROJECT WAS ASKED TO DO:\n__TICKET_BLOCK__\n\n__TOOL_LINE__\n\n# What is in scope\n\nFOUR QUESTIONS ONLY:\n1. Does the generated prompt state anything about this project that is FALSE?\n2. Is the generated prompt NARROWED TO ONE STORY OR CALL, or does a slot NO LONGER FIT ITS SENTENCE? (See \"A prompt narrowed to one call\" below.)\n3. Was any part of the template LEFT OUT although it applies to this project, or was anything ADDED that is false of this project or serves only one story or call? A part left out is a finding when its reason is false of the codelines or the kind of project; quote the template's words that were left out as the claim.\n4. Does the generated prompt refer to the TICKET IN SCOPE at all — its key, title, subject, components, requirements or files, or a path that belongs to this run (a run folder, a copy of a codeline) — in any wording, including as an example? This prompt is kept with the codeline and reused for every later story, so any such reference is a finding; quote it as the claim. Only the codeline's own structure, conventions and manifests may be named.\n\nA claim is in scope when it can be checked against a repository — a path, a file, a directory, a dependency, a command, a framework, a convention, a symbol, an ownership statement ('X owns Y'). Open the codelines and check it.\n\nExamples of a finding:\n- it names a test directory, file suffix or framework this codeline does not use\n- it names a dependency, script or command the manifest does not declare\n- it asserts a file, module or symbol exists that does not\n- it attributes behaviour to a file that does not contain it\n- it describes a codeline this project does not have, or confuses two that it does\n- it instructs the agent to run something this codeline cannot run\n\n# A prompt narrowed to one call\n\nThe generated prompt is not written for the ticket in scope now. It is reused for every story and every call this project makes to the agent, and each call's specifics — the role for the turn, the file to write, the command to run, the diff, the story — arrive through the slots (the SCREAMING_SNAKE tokens between double underscores) at run time. Compare it with the template, slot by slot, and report as a finding:\n- a statement true only for one story or one call — this ticket's component, a file or path one story will write, a command aimed at one story's file — written where the template leaves that to a slot. It is a finding even when it is true today: the next story receives it as an instruction.\n- a slot that no longer fits its sentence: in the template the slot completes or sits inside a sentence; in the generated prompt the words around it were moved, completed by hand, or rewritten, so the run-time value would land in the wrong place or be said twice. Quote the template's words around that slot and the generated prompt's.\nFor these findings `claim` quotes the generated text, `checked` names the template slot you compared it with, and `found` says what the template has there. Give no `verification` field: this is read from the two texts, not from the repository.\n\n# Before you call anything absent: SEARCH for it\n\nA path in a generated prompt is frequently ABBREVIATED rather than wrong. Looking at the literal\nstring, finding nothing there, and reporting a false claim is the single most common way this\nreview does damage — it rejects a prompt that was RIGHT about the project, the generator rewrites\nthe whole thing to escape a finding that was not real, and in rewriting it drops the placeholders\nthe pipeline depends on. Three attempts of that aborts the run.\n\nSo, for every path, file, directory or symbol the prompt names:\n\n1. SEARCH the codeline for it by BASENAME before concluding it does not exist. `src/routes/checkouts/[checkoutId].ts`\n   and `src/pages/api/checkouts/[checkoutId].ts` are both a SHORTENED form of\n   `src/pages/api/v1/ecommerce/checkouts/[checkoutId].ts`, which exists — that is a near-miss path,\n   NOT a false claim, and it is not a finding.\n2. An IMPRECISE path that RESOLVES to a real file is not a finding. Neither is a partial path, a\n   path missing intermediate directories, or a file named without its directory.\n   A NAME MAY BE A DIRECTORY. A file glob such as **/Name* matches files, not directories, and a\n   text search matches contents, not folder names — neither can show you a directory. Before you\n   call a component, module or folder absent, list its parent directory and look for it there.\n3. Report it ONLY when the thing genuinely does not exist anywhere in the codeline — no file of\n   that name, no such dependency in the manifest, no such symbol in the sources.\n\nAbsence at one exact path is not absence from the repository. If you did not search, you do not\nknow, and \"I did not find it where the prompt said\" is not a finding you may report.\n\n# What is NOT in scope\n\nDo not review wording, tone, length, structure or ambition. Do not propose improvements. Do not object that the prompt is too close to, or too far from, the template — how far it may diverge is decided elsewhere, and the placeholder contract is already enforced mechanically. (A prompt narrowed to one call, or a slot that no longer fits its sentence, is not a question of distance — report it as above.)\n\nA prompt that says nothing false and serves every call is SOUND, however plain it is.\n\n# Evidence\n\nReturn every defect you can evidence, and nothing you cannot. For each finding, say what you CHECKED and what you FOUND, naming the file or manifest you read. A finding without a check is an opinion, and an opinion about a prompt is not a defect.\n\nWhere a finding turns on whether a named path or dependency is present, fill in the verification field as well as the prose. The pipeline re-runs that exact check against the repository and DISCARDS any finding the check refutes — so a careless reading costs nothing, and a correct one is confirmed independently of how convincingly you argued it.\n\nIf every claim checks out, return no findings. An empty finding list from a review that RAN is the correct answer for a sound prompt.\n\n# How to return the verdict\n\nEmit the verdict INLINE as the last thing you write, wrapped in these exact tags. Do not write it\nto a file, and do not use a tool to deliver it — a verdict delivered any other way is not read, and\nthe prompt is then installed unreviewed.\n\n<PROMPT_REVIEW>\n{\"falseClaims\": []}\n</PROMPT_REVIEW>\n\n`falseClaims` is a list of the defects you evidenced. Each entry is an object:\n\n- `claim`       — the false statement, quoted from the generated prompt\n- `checked`     — what you opened or ran to test it, naming the file or manifest\n- `found`       — what was actually there\n- `verification` — when the finding turns on a named path or dependency being present or absent,\n                  an object stating what to re-check, so the pipeline can confirm it independently\n\nTHE ROLES THIS PROJECT MINTED, which is the ground truth for any claim naming an agent:\n\n__ROSTER_BLOCK__\n\nA prompt naming one of these is stating a FACT, not inventing one. Check the list before calling a\nrole false — an unverifiable claim is not a false claim, and rejecting one costs a regeneration and\nteaches the generator nothing.\n\nTHE BLOCK IS THE WHOLE ANSWER. Nothing you write outside it is read — the consumer matches the\ntags and discards everything else. Do not narrate your investigation, do not summarise what you\nchecked, and do not restate the prompt back. Put your evidence INSIDE `checked` and `found` on the\nfinding it belongs to, where it is kept; anywhere else it is thrown away.\n\nMeasured 2026-08-27: reviews averaged 3,366 output tokens to deliver a 13-token verdict. Every one\nof those tokens was billed and 99% of them were discarded unread.\n\nAn empty list is the correct verdict for a sound prompt. Emit the block either way: the block is\nhow a review that RAN is distinguished from one that did not run at all.\n",
   "placeholders": [
     "__CODELINE_BLOCK__",
     "__GENERATED_BODY__",

package/orchestrations/prompts/templates/roster-review.json

@@ -21,9 +21,10 @@
     "already declares - the artefacts this run requires, the seam that produces each, and which",
     "roster member resolves to which seam - and asked whether the team covers them. No role or kind",
     "is named in this prompt; the coverage block is derived.",
-    "v2 (operator, 2026-10-24: the roster minted for AMSD-2974 named every agent after the ticket's subject (<codeline>-toast-detective, toast-accessibility-engineer) and its briefs described that one ticket; the roster and its prompts are cached per codeline and reused for every later story, so the next ticket on these codelines would inherit them). A role is the codeline's, for every story it will ever be given."
+    "v2 (operator, 2026-10-24: the roster minted for AMSD-2974 named every agent after the ticket's subject (<codeline>-toast-detective, toast-accessibility-engineer) and its briefs described that one ticket; the roster and its prompts are cached per codeline and reused for every later story, so the next ticket on these codelines would inherit them). A role is the codeline's, for every story it will ever be given.",
+    "v3 (operator, 2026-10-24: \"The purpose of re caching was to remove user story references in profiles and prompts\" — zero, not \"zero except marked examples\"): the sets are kept per codeline and reused for every later story; any reference to the ticket in scope, however labelled, is inherited by the next story's agents. Run 14's fresh mint had codeline-level names and briefs of seven \"worked example: for AMSD-2974 …\" sentences each, approved under the earlier wording."
   ],
-  "body": "THE ROSTER JUST MINTED FOR THIS PROJECT — review it, both as individual briefs and AS A TEAM.\n\nWHAT THIS RUN NEEDS THE TEAM TO PRODUCE, and who in this roster can produce it:\n__COVERAGE_BLOCK__\n\nA roster can be made entirely of well-formed agents and still be unable to do the work. Where a\nline above says NOBODY, no one in this roster can produce something the run requires — that is a\ndefect of the ROSTER, and it is invisible to reading briefs one at a time, because an absent role\nhas no brief to find fault with. Report it as a blocking finding naming what cannot be produced\nand what kind of role would produce it.\n\nNow review every brief below:\n\n__BRIEF_BLOCK__\n\nTHE CODELINES THESE BRIEFS DESCRIBE, and what each one declares:\n__CODELINE_BLOCK__\n\nTHE WORK THE PROJECT WAS ASKED TO DO:\n__TICKET_BLOCK__\n\n__DOC_SECTION__\n\n__TOOL_LINE__\n\nTHE PIPELINE STAGES THAT RUN ALONGSIDE THIS ROSTER:\n\n__PIPELINE_STAGES__\n\nA ROSTER IS NOT THE WHOLE PIPELINE. A brief may correctly defer work to a stage above rather than\nto a role beside it, and a brief that tells its implementer to leave such work alone is describing\nthe pipeline accurately, not inventing cover. Check any such claim against the list above before\ncalling it false: the absence of a matching ROLE is not evidence when the brief named a STAGE.\n\nWhere the list above does not contain the stage a brief names, that IS a finding, and a blocking\none — the implementer has been told to rely on something that will never run.\n\nReturn every defect you can evidence, and nothing you cannot.\n\nWhere a finding turns on whether a named dependency or path is present in a codeline, fill in\nthe verification field as well as writing the prose. The pipeline re-runs that exact check\nagainst the repository and DISCARDS any finding the check refutes — so a careless reading\ncosts nothing, and a correct one is confirmed independently of how convincingly you argued it.\n\nA ROLE OUTLIVES THE TICKET. This roster is kept with its codelines and reused for every story they are given later. A role minted for\nthe work in scope now rather than for the codeline — named after the current story's subject, component or ticket, or briefed so that\nit would mislead an implementer on a different story of the same codeline — is a blocking finding: name the role, quote the words,\nand say what the codeline-level role would be. A brief that names the current ticket's subject or files only as marked examples of the\ncodeline's conventions is not this finding.\n",
+  "body": "THE ROSTER JUST MINTED FOR THIS PROJECT — review it, both as individual briefs and AS A TEAM.\n\nWHAT THIS RUN NEEDS THE TEAM TO PRODUCE, and who in this roster can produce it:\n__COVERAGE_BLOCK__\n\nA roster can be made entirely of well-formed agents and still be unable to do the work. Where a\nline above says NOBODY, no one in this roster can produce something the run requires — that is a\ndefect of the ROSTER, and it is invisible to reading briefs one at a time, because an absent role\nhas no brief to find fault with. Report it as a blocking finding naming what cannot be produced\nand what kind of role would produce it.\n\nNow review every brief below:\n\n__BRIEF_BLOCK__\n\nTHE CODELINES THESE BRIEFS DESCRIBE, and what each one declares:\n__CODELINE_BLOCK__\n\nTHE WORK THE PROJECT WAS ASKED TO DO:\n__TICKET_BLOCK__\n\n__DOC_SECTION__\n\n__TOOL_LINE__\n\nTHE PIPELINE STAGES THAT RUN ALONGSIDE THIS ROSTER:\n\n__PIPELINE_STAGES__\n\nA ROSTER IS NOT THE WHOLE PIPELINE. A brief may correctly defer work to a stage above rather than\nto a role beside it, and a brief that tells its implementer to leave such work alone is describing\nthe pipeline accurately, not inventing cover. Check any such claim against the list above before\ncalling it false: the absence of a matching ROLE is not evidence when the brief named a STAGE.\n\nWhere the list above does not contain the stage a brief names, that IS a finding, and a blocking\none — the implementer has been told to rely on something that will never run.\n\nReturn every defect you can evidence, and nothing you cannot.\n\nWhere a finding turns on whether a named dependency or path is present in a codeline, fill in\nthe verification field as well as writing the prose. The pipeline re-runs that exact check\nagainst the repository and DISCARDS any finding the check refutes — so a careless reading\ncosts nothing, and a correct one is confirmed independently of how convincingly you argued it.\n\nA ROLE OUTLIVES THE TICKET — ZERO REFERENCES TO THE TICKET IN SCOPE. This is kept with the codeline and reused for every later story on it, so it refers to no\nticket at all — not the key, title, subject, components, requirements or files of the story in scope, not even as an example. Examples\ncome from the codeline itself: its structure, conventions, manifests and how to verify there. Anything that could only have been written\nwith this ticket in view is a defect.\nA role or brief that refers to the current ticket — by key, subject, component, requirement or file, in any wording, including \"as an\nexample\" — is a BLOCKING finding: name the role, quote the words, and say what the codeline-level wording would be.",
   "description": "Review every brief in a freshly minted roster and report evidenced defects.",
   "id": "roster-review",
   "placeholders": [
@@ -35,7 +36,7 @@
     "__TICKET_BLOCK__",
     "__TOOL_LINE__"
   ],
-  "version": 2,
+  "version": 3,
   "seams": [
     "roster-review"
   ],

package/orchestrations/prompts/templates/set-fidelity-check.json

@@ -1,6 +1,6 @@
 {
   "id": "set-fidelity-check",
-  "version": 2,
+  "version": 3,
   "seams": [],
   "layer": "engine",
   "description": "A judge reads a codeline's minted roster and reusable prompts against the ticket they were minted for and reports what is geared to that ticket rather than to the codeline.",
@@ -12,7 +12,8 @@
   ],
   "$why": [
     "v1 (operator, 2026-10-24: \"We need some post pause 1 checkpoints to ensure no contamination in codeline level prompts and profiles\"): run 13's roster named every agent after the ticket's subject and ~half its reusable prompts described that one ticket; the sets are cached per codeline and reused for every later story. Judged by an agent, not a word list; run by the pre-launch of the leg after pause 1 and reported at pause 1.",
-    "v2 (live, 2026-10-24): a codeline's whole prompt set in one call was 908 KB and the judge answered about its own context limit; the prompts are judged one by one by the pipeline's own reviewer as they are built (each copy records its judges), so this judge reads the roster only."
+    "v2 (live, 2026-10-24): a codeline's whole prompt set in one call was 908 KB and the judge answered about its own context limit; the prompts are judged one by one by the pipeline's own reviewer as they are built (each copy records its judges), so this judge reads the roster only.",
+    "v3 (operator, 2026-10-24: \"The purpose of re caching was to remove user story references in profiles and prompts\" — zero, not \"zero except marked examples\"): the sets are kept per codeline and reused for every later story; any reference to the ticket in scope, however labelled, is inherited by the next story's agents. Run 14's fresh mint had codeline-level names and briefs of seven \"worked example: for AMSD-2974 …\" sentences each, approved under the earlier wording."
   ],
-  "body": "You judge the agent roster a pipeline minted for ONE codeline and will REUSE for every later story on it: its agents' names and\nbriefs. It was minted while this ticket was in scope:\n\nTicket __TICKET_KEY__: __TICKET_TITLE__\nCodeline: __CODELINE__\n\nTHE ROSTER (each agent: name, kind, brief):\n__ROSTER__\n\nReport every agent that is geared to THIS ticket rather than to the codeline: named after the ticket's subject, component or key, or\nbriefed so that it takes this ticket's subject, components, files or requirements as its subject or as standing instruction — an\nimplementer on a DIFFERENT story of this codeline would be misled. A mention of the ticket's subject or files only as a marked example\nof the codeline's conventions is not geared. Quote the words. Report nothing you cannot quote. Answer in the structured form you are\ngiven; `geared` is empty when nothing is geared."
+  "body": "You judge the agent roster a pipeline minted for ONE codeline and will REUSE for every later story on it: its agents' names and\nbriefs. It was minted while this ticket was in scope:\n\nTicket __TICKET_KEY__: __TICKET_TITLE__\nCodeline: __CODELINE__\n\nTHE ROSTER (each agent: name, kind, brief):\n__ROSTER__\n\nReport every agent whose name or brief refers to THIS ticket in any way — its key, title, subject, components, requirements or files —\nincluding a mention labelled as an example. The roster is reused for every later story on this codeline, so no reference to this ticket\nmay be in it; a codeline's own conventions, structure and manifests are the only examples allowed. Quote the words. Report nothing you\ncannot quote. Answer in the structured form you are\ngiven; `geared` is empty when nothing is geared."
 }

package/orchestrations/scripts/lib/engine-prompt.js

@@ -202,10 +202,9 @@ function templateLayerOf(id) {
   try {
     const own = JSON.parse(fs.readFileSync(path.join(templatesDir(), `${id}.json`), 'utf8'));
     if (own && own.layer === 'project') return 'project';
-    // A TEMPLATE THAT DECLARES ITSELF BOOTSTRAP runs inside the mint, before this project's prompt layer exists (survey-review,
-    // test-ownership: read by the estate survey and the roster mint), and renders from the template as the registry's bootstrap
-    // seams do — run 14, 2026-10-24: a project never minted could not be minted ("project-authority prompt missing")
-    if (own && own.layer === 'bootstrap') return 'bootstrap';
+    // Any other layer a template declares (bootstrap: survey-review, test-ownership — read INSIDE the mint before this project's prompt
+    // layer exists) leaves the decision to the registry below, which renders them from the template. Run 14, 2026-10-24: the two had
+    // declared `layer: project` and the routing above, added that morning, sent the mint to project copies that cannot exist yet.
   } catch { /* no template of that id here: the registry decides, as before */ }
   const registryPath = path.join(__dirname, '..', '..', 'agents', 'invocation-profiles.json');
   let reg;

package/orchestrations/scripts/lib/llm-settings-resolve.js

@@ -267,6 +267,8 @@ function resolveRunner(runnerName, { projectConfigDir, defaultsFile } = {}) {
     toolNames: declared.toolNames && typeof declared.toolNames === 'object' ? declared.toolNames : {},
     // How this runner carries an agent's standing instructions, separate from the task.
     siChannel: declared.siChannel && typeof declared.siChannel === 'object' ? declared.siChannel : null,
+    // the pipeline's own tool plugins this runner hosts (plugins/*-plugin.js), served to the agent as its tools (lib/pipeline-tools-mcp.js)
+    hostedToolPlugins: Array.isArray(declared.hostedToolPlugins) ? declared.hostedToolPlugins : [],
   };
 }
 /** Every runner the active stack declares, by name. */

package/orchestrations/scripts/lib/pipeline-tools-mcp.js

@@ -0,0 +1,102 @@
+#!/usr/bin/env node
+'use strict';
+// THE PIPELINE'S TOOLS AS CLAUDE CODE TOOLS — an MCP server over the hosted tool plugins (operator, 2026-10-24: "What about tools?"
+// / "not using the proper interface is not permitted"). Until now a plain-Claude agent reached codegraph, the search and the
+// package-symbol resolver only as shell scripts through Bash, named by variables (config/pipeline-tool-commands.json): a seam
+// granted read-only (no Bash) could not call them at all, and in plan mode a Bash call outside Claude's read-only set is denied.
+// Here the SAME plugin modules the codemie-web runner hosts (its runner declaration's hostedToolPlugins — plugins/*-plugin.js,
+// each exporting tools[] of {name, description, permission, definition.inputSchema, execute}) are served over MCP stdio, so an
+// agent is granted them by name (--tools mcp__<server>__<tool>), and a tool whose permission is 'safe' is annotated read-only,
+// which is what lets it run in plan mode (proven 2026-10-24 on Claude Code 2.1.310: without the annotation plan mode refuses it).
+//
+//   node pipeline-tools-mcp.js <runner-name>        serve the runner's hostedToolPlugins (declaration read from the active set)
+//   node pipeline-tools-mcp.js --modules a.js,b.js  serve these plugin modules (tests)
+//
+// Protocol: JSON-RPC 2.0, one message per line, MCP 2024-11-05 — initialize, tools/list, tools/call; nothing else.
+const fs = require('fs');
+const path = require('path');
+const readline = require('readline');
+
+const ORCH = path.join(__dirname, '..', '..');
+
+/** The plugin modules a runner hosts, from the active set's declaration (lib/llm-settings-resolve.js). */
+function hostedModulesFor(runnerName) {
+  // eslint-disable-next-line global-require
+  const { resolveRunner } = require('./llm-settings-resolve.js');
+  const runner = resolveRunner(runnerName, { projectConfigDir: process.env.EPAM_PROJECT_CONFIG_DIR || undefined });
+  return ((runner && runner.hostedToolPlugins) || []).map((m) => path.resolve(ORCH, m));
+}
+
+/** Every tool the modules export, as MCP lists them: safe → read-only; the plugin's own input schema and description. */
+function toolsOf(modules) {
+  const out = [];
+  for (const m of modules) {
+    // eslint-disable-next-line global-require, import/no-dynamic-require
+    const mod = require(m);
+    for (const t of ((mod && mod.tools) || [])) {
+      const name = t.name || (t.definition && t.definition.name);
+      if (!name) continue;
+      const def = t.definition || {};
+      out.push({
+        name,
+        description: t.description || def.description || '',
+        inputSchema: def.inputSchema || def.input_schema || { type: 'object', properties: {} },
+        annotations: { readOnlyHint: t.permission === 'safe', destructiveHint: t.permission !== 'safe' },
+        execute: t.execute,
+      });
+    }
+  }
+  return out;
+}
+
+/** A plugin result as MCP content: the plugin returns {content, isError} (see codegraph-plugin.js). */
+function asMcpResult(r) {
+  if (r && typeof r === 'object' && 'content' in r) {
+    const text = typeof r.content === 'string' ? r.content : JSON.stringify(r.content);
+    return { content: [{ type: 'text', text }], isError: !!r.isError };
+  }
+  return { content: [{ type: 'text', text: typeof r === 'string' ? r : JSON.stringify(r == null ? {} : r) }], isError: false };
+}
+
+function serve(modules, io = { input: process.stdin, write: (s) => process.stdout.write(s) }) {
+  const tools = toolsOf(modules);
+  const byName = new Map(tools.map((t) => [t.name, t]));
+  const send = (o) => io.write(`${JSON.stringify(o)}\n`);
+  const rl = readline.createInterface({ input: io.input });
+  rl.on('line', async (line) => {
+    let m; try { m = JSON.parse(line); } catch { return; }
+    if (m.method === 'initialize') {
+      return send({ jsonrpc: '2.0', id: m.id, result: { protocolVersion: '2024-11-05', capabilities: { tools: {} }, serverInfo: { name: 'pipeline', version: '1' } } });
+    }
+    if (m.method === 'notifications/initialized' || m.method === 'ping') return m.id !== undefined ? send({ jsonrpc: '2.0', id: m.id, result: {} }) : undefined;
+    if (m.method === 'tools/list') {
+      return send({ jsonrpc: '2.0', id: m.id, result: { tools: tools.map(({ name, description, inputSchema, annotations }) => ({ name, description, inputSchema, annotations })) } });
+    }
+    if (m.method === 'tools/call') {
+      const t = byName.get(m.params && m.params.name);
+      if (!t) return send({ jsonrpc: '2.0', id: m.id, error: { code: -32602, message: `unknown tool: ${m.params && m.params.name}` } });
+      try {
+        const r = await t.execute((m.params && m.params.arguments) || {});
+        return send({ jsonrpc: '2.0', id: m.id, result: asMcpResult(r) });
+      } catch (e) {
+        return send({ jsonrpc: '2.0', id: m.id, result: { content: [{ type: 'text', text: `tool ${t.name} failed: ${e && e.message}` }], isError: true } });
+      }
+    }
+    if (m.id !== undefined) send({ jsonrpc: '2.0', id: m.id, error: { code: -32601, message: `method not found: ${m.method}` } });
+  });
+  return { tools: tools.map((t) => t.name) };
+}
+
+/** The --mcp-config document the hub hands the CLI: this server, for this runner. */
+function mcpConfig(runnerName, nodeBin = process.execPath) {
+  return { mcpServers: { pipeline: { command: nodeBin, args: [__filename, runnerName], env: { EPAM_PROJECT_CONFIG_DIR: process.env.EPAM_PROJECT_CONFIG_DIR || '' } } } };
+}
+
+if (require.main === module) {
+  const a = process.argv.slice(2);
+  const modules = a[0] === '--modules' ? String(a[1] || '').split(',').filter(Boolean).map((m) => path.resolve(m)) : hostedModulesFor(a[0]);
+  if (!modules.length) { process.stderr.write(`[pipeline-tools-mcp] no hosted tool plugins for runner '${a[0] || ''}'\n`); process.exit(2); }
+  serve(modules);
+}
+
+module.exports = { hostedModulesFor, toolsOf, serve, mcpConfig, asMcpResult };

package/orchestrations/scripts/lib/project-prompt-builder.js

@@ -1433,17 +1433,32 @@ function clearCompletionMarker({ outDir, codeline } = {}) {
  * 2026-10-24): which kind of project this is — brownfield (existing code) or greenfield (built from nothing) — every codeline in
  * scope and whether its code exists yet, and the tickets, so it knows the kind of work (never the subject of the prompt).
  */
+/**
+ * THE ROLES AS THE PROMPT GENERATOR IS TOLD THEM: name and kind, nothing else. A role's rationale is the mint's reason for
+ * proposing it THIS run — written against the ticket in scope ("AMSD-2974 requires toast accessibility fixes in …", live
+ * 2026-10-24, every one of six roles) — and the generator wrote it into prompts kept with the codeline. The rationale is run
+ * provenance; it stays in the mint's own record (logs/agent-mint.json) and never enters codeline-level context.
+ */
+function mintedRolesBlock(roles) {
+  const list = Array.isArray(roles) ? roles.filter((m) => m && m.name) : [];
+  return list.length ? list.map((m) => `- ${m.name} [${m.kind || ''}]`).join('\n') : '(none minted this run)';
+}
+
 function useCaseContext({ projectConfigDir, stories, codelines, env = process.env }) {
   const kind = env.EPAM_BROWNFIELD === '1'
     ? 'brownfield — the work changes code that already exists in each codeline'
     : 'greenfield — the work builds the codeline from nothing; there is no existing code to read or preserve';
   const cl = (codelines || []).map((c) => `- ${c.name || c.codeline}: ${c.path && fs.existsSync(c.path) ? `code at ${c.path}` : 'no code yet'}`);
+  // THE TICKETS ARE NOT NAMED. This line read "Tickets in scope: AMSD-2974: Toast Notification …", and the generator wrote
+  // the ticket into prompts kept with the codeline (live 2026-10-24, two drafts of two). The use case is the kind of project
+  // and its codelines; how many tickets reach them is all a reusable prompt may be told.
   return [`Project: ${path.basename(String(projectConfigDir || ''))}`, `Kind of project: ${kind}`,
     ...(cl.length ? ['Codelines in scope:', ...cl] : []),
-    `Tickets in scope: ${(stories || []).map((t) => `${t.jiraKey || t.id}: ${t.title || ''}`).join(' | ')}`].join('\n');
+    `Tickets reaching these codelines: ${(stories || []).length} (what they ask for is given to the agent per call, never here)`].join('\n');
 }
 
 module.exports = {
+  mintedRolesBlock,
   useCaseContext, buildProjectPrompts, healContext, renderGeneratorPrompt, provisioningList, rolesIdentity, GEN_BODY_SLOT,
   PROJECT_PROMPT_GENERATOR_ID, answerBudgetChars, promptParts,
   writeCompletionMarker, clearCompletionMarker, promptInputsDigest, codelinePromptsComplete,

package/orchestrations/scripts/lib/roster-mint-cycle.js

@@ -0,0 +1,113 @@
+'use strict';
+// THE ROSTER REVIEW-AND-CORRECTION CYCLE, as the mint step runs it: the reviewer judges the minted roles as briefs and as a team; a
+// blocking finding that names a role indicts it; the indicted are cleared and re-minted with the findings as corrective context, the
+// retained kept; until a cycle has no blocking finding or the cycles run out. Extracted from mint-agents-step.js (2026-10-24) so the
+// cycle is one unit the live proof can execute on a sample mint — before that, the only way to run it was the whole Agents stage.
+// Behaviour unchanged: the step's own log lines, files (agent-mint-cycle<n>.json) and give-up rules.
+const fs = require('fs');
+const path = require('path');
+
+/**
+ * @param {object} o
+ * @param {object} o.spec            spec-mode-runner (reviewRoster, mintProjectAgents)
+ * @param {object} o.rosterLib       lib/agent-roster.js (partitionRosterFindings, clearProjectRoster)
+ * @param {Array}  o.mintedDetail    the roles the mint just produced (this run)
+ * @param {number} o.maxCycles       review cycles; the last one's findings are surfaced, not corrected
+ * @param {function} o.log           one line of the step's log
+ * @returns {Promise<{mintedDetail: Array, mintedNames: string[], review: object}>} review.cycles = cycles run
+ */
+async function reviewAndCorrectRoster({
+  spec, rosterLib, promptExec, stories, docs, deps, codelines, toolGrant, profilesPath, agentsDir, logDir, repoPath,
+  projectConfigDir, mintedDetail, maxCycles, log,
+}) {
+  let _mintedDetail = Array.isArray(mintedDetail) ? mintedDetail : [];
+  let _mintedNames = _mintedDetail.map((m) => m.name);
+
+  const runRosterReview = async () => {
+    if (!_mintedDetail.length) return { verdict: 'nothing_to_review', findings: [], reviewed: 0 };
+    process.env.EPAM_AGENT_NAME = 'roster-review';
+    try {
+      const liveProfiles = JSON.parse(fs.readFileSync(profilesPath, 'utf8'));
+      let projectProfiles = {};
+      try {
+        const _pp = path.join(projectConfigDir || '', 'agent-profiles.json');
+        projectProfiles = JSON.parse(fs.readFileSync(_pp, 'utf8'));
+      } catch { /* a project with no minted profiles yet has none to add */ }
+      return await spec.reviewRoster({
+        promptExec, minted: _mintedDetail, profiles: liveProfiles, projectProfiles,
+        codelines, tickets: stories, referencedDocs: docs,
+        logDir, repoPath, toolGrant,
+      });
+    } catch (err) {
+      log(`roster review FAILED: ${err && err.message}`);
+      return { verdict: 'review_failed', findings: [], reviewed: 0, error: String(err && err.message) };
+    }
+  };
+
+  const reportReview = (rv, n) => {
+    const blocking = rv.findings.filter((f) => f && f.severity === 'blocking');
+    log(`roster review (cycle ${n}): ${rv.verdict} — ${rv.findings.length} finding(s), ${blocking.length} blocking`);
+    for (const f of rv.findings) {
+      log(`  [${f.severity}] ${f.agent}: ${f.claim}`);
+      log(`     checked: ${f.checked}`);
+      log(`     found:   ${f.found}`);
+      if (f.remedy) log(`     remedy:  ${f.remedy}`);
+    }
+  };
+
+  let cycle = 1;
+  let review = { verdict: 'not_run', findings: [], reviewed: 0 };
+
+  while (_mintedDetail.length && cycle <= maxCycles) {
+    review = await runRosterReview();
+    const blocking = review.findings.filter((f) => f && f.severity === 'blocking');
+    reportReview(review, cycle);
+    if (!blocking.length || cycle === maxCycles) break;
+
+    const { indicted: _indicted, retained: _retained, gaps: _gapFindings, superfluous: _superfluous } =
+      rosterLib.partitionRosterFindings(blocking, _mintedDetail);
+
+    log(`cycle ${cycle}: ${blocking.length} blocking finding(s) — ${_indicted.length} agent(s) indicted, ${_retained.length} retained`
+      + `${_gapFindings ? `, ${_gapFindings} finding(s) name no agent (roster gaps)` : ''}`
+      + `${_superfluous && _superfluous.length ? `, ${_superfluous.length} superfluous (no replacement needed)` : ''}`);
+
+    if (!_indicted.length && !_gapFindings) {
+      log('  no blocking finding names an agent in this roster — nothing to correct; surfacing the findings instead of re-minting');
+      break;
+    }
+
+    const cleared = rosterLib.clearProjectRoster(agentsDir, profilesPath, _indicted);
+    for (const c of cleared) {
+      const isSuper = _superfluous && _superfluous.includes(c);
+      log(`  − ${c} (${isSuper ? 'superfluous — no replacement' : 'indicted, being replaced'})`);
+    }
+    for (const r of _retained) log(`  = ${r.name} (passed review, kept)`);
+
+    const _replacedForMint = _mintedDetail.filter(
+      (m) => _indicted.includes(m.name) && !(_superfluous && _superfluous.includes(m.name)));
+    const _superfluousForMint = _mintedDetail.filter(
+      (m) => _superfluous && _superfluous.includes(m.name));
+
+    const remint = await spec.mintProjectAgents({
+      promptExec, tickets: stories, referencedDocs: docs, declaredDependencies: deps,
+      codelines, toolGrant, profilesPath, agentsDir,
+      logDir, repoPath, correctiveFindings: blocking,
+      retainedAgents: _retained,
+      replacedAgents: _replacedForMint,
+      superfluousAgents: _superfluousForMint,
+    });
+    _mintedDetail = [..._retained, ...remint.minted];
+    _mintedNames = _mintedDetail.map((m) => m.name);
+    fs.writeFileSync(path.join(logDir, `agent-mint-cycle${cycle + 1}.json`), JSON.stringify(remint, null, 2));
+    for (const m of remint.minted) {
+      const tag = m.kind === 'investigator' ? `investigator:${m.codeline || '(no codeline!)'}` : 'implementer';
+      log(`  + [${tag}] ${m.name} — ${m.rationale}`);
+    }
+    cycle += 1;
+  }
+
+  review.cycles = cycle;
+  return { mintedDetail: _mintedDetail, mintedNames: _mintedNames, review };
+}
+
+module.exports = { reviewAndCorrectRoster };

package/orchestrations/scripts/lib/roster-seams.js

@@ -0,0 +1,189 @@
+/**
+ * roster-seams.js — the two seams that derive a project's roster, as ONE piece of code.
+ *
+ * `produce` asks the roster specialiser for its delta and lands it where lib/project-roster.js
+ * composes it; `review` asks project-roster-review to falsify the composed roster. They were
+ * closures inside mint-agents-step.js; the seam harness (tools/seam-harness.js) needs to run
+ * exactly them on a recorded run's inputs, so they live here and the step calls them. Nothing
+ * about either seam changed in the move — the text below is the step's, verbatim.
+ */
+'use strict';
+
+const fs = require('fs');
+const path = require('path');
+
+/**
+ * rosterSeams(ctx) -> { produce, review }
+ * ctx: { spec, promptExec, projectConfigDir, LOG_DIR, AGENTS_DIR, REPO_PATH, codelines, stories,
+ *        mintedDetail, survey, toolGrant }
+ */
+/**
+ * THE CODELINES, WITH WHAT THE TICKETS DECLARE FOR THEM. On a brownfield tree the specialiser
+ * reads the code; on a greenfield one there is no code, and the only source of a path is the
+ * tickets' own declaration (technicalNotes.files and the paths their text names). Run
+ * 20260916T234139Z: handed ticket TITLES only, the specialiser wrote src/client.ts for a client the
+ * PRD declares at src/skyscanner/client.ts; the reviewer found the contradiction on every attempt.
+ * The declared paths are DATA the tickets already carry (lib/agent-roster.js declaredPathsOf, the
+ * same derivation the mint's brief check uses) — both seams receive them in the same line.
+ */
+function codelineContext(codelines, stories) {
+  const declared = require('./agent-roster.js').declaredPathsOf(stories);
+  const suffix = declared.length ? ` — paths the tickets declare: ${declared.join(', ')}` : '';
+  return (Array.isArray(codelines) ? codelines : [])
+    .map((c) => `- ${c.name} (${c.path})${c.dependencies && c.dependencies.length ? ` deps: ${c.dependencies.join(', ')}` : ''}${suffix}`)
+    .join('\n');
+}
+
+function rosterSeams({ spec, promptExec, projectConfigDir, LOG_DIR, AGENTS_DIR, REPO_PATH, codelines, stories, prd, mintedDetail, survey, toolGrant }) {
+  const { seamInvocationEnv } = require('./seam-invocation.js');
+  // eslint-disable-next-line global-require
+  const { renderEngineTemplate } = require('./engine-prompt.js');
+  const { refusalBlock } = require('./refusal-block.js');
+  const renderSpecialisation = (vals) => renderEngineTemplate('roster-specialisation', vals);
+
+  // PRD configuration block — same derivation as spec-mode-runner.js prdConfigurationBlock.
+  // Strip $-prefixed comment keys; render empty string when the PRD declares no configuration.
+  const prdConfigurationBlock = (() => {
+    if (!prd || !prd.configuration) return '';
+    const cfg = Object.fromEntries(
+      Object.entries(prd.configuration).filter(([k]) => !k.startsWith('$')),
+    );
+    if (!Object.keys(cfg).length) return '';
+    return renderEngineTemplate('prd-configuration-block', {
+      __PRD_CONFIGURATION_JSON__: JSON.stringify(cfg, null, 2),
+    });
+  })();
+
+// THE AGENT WRITES THE FILE. The pipeline hands it the canonical copy and a destination,
+// then judges the artefact — it does not compose personas itself, because deciding what an
+// agent must know about a codeline is judgement, not substitution.
+const produce = async ({ canonicalCopyPath, outPath, refusal, attempt }) => {
+  process.env.EPAM_AGENT_NAME = 'roster-specialiser';
+  // The SAME context the prompt builder is given, computed the same way — a derivation that
+  // sees different facts than its sibling stage is two projects, not one.
+  const prompt = renderSpecialisation({
+    // THE VOCABULARY THE ANSWER IS JUDGED AGAINST. Read from the registry rather than written
+    // out here: a hand-kept second copy of a closed list only ever drifts from the list.
+    __DECLARED_SEAMS__: (() => {
+      try {
+        const _reg = JSON.parse(fs.readFileSync(path.join(__dirname, '..', '..', 'agents', 'invocation-profiles.json'), 'utf8'));
+        return Object.keys(_reg.profiles || {}).sort().map((s) => `- ${s}`).join('\n');
+      } catch { return ''; }
+    })(),
+    // THE PERSONAS THEMSELVES, NOT WHERE THEY LIE. Pointed at a folder under the install's logs,
+    // the agent was handed a local path (operator, 2026-10-01: relative paths only) that a CodeMie
+    // web plugin, rooted at the codelines, cannot even reach. The run's own copy, every entry.
+    __CANONICAL_PERSONAS__: (() => {
+      const c = JSON.parse(fs.readFileSync(canonicalCopyPath, 'utf8'));
+      return Object.keys(c).filter((n) => typeof c[n] === 'string' && c[n].trim())
+        .map((n) => `--- AGENT: ${n}\n${c[n].trim()}`).join('\n\n');
+    })(),
+    // the same use case the prompt generator is told (lib/project-prompt-builder.js useCaseContext): kind of project and its
+    // codelines, not the tickets — a persona is kept with the codeline (live 2026-10-24: personas carried the ticket's subject)
+    __PROJECT_CONTEXT__: [
+      require('./project-prompt-builder.js').useCaseContext({ projectConfigDir, stories, codelines }),
+      mintedDetail.length
+        ? `Agents this project minted: ${mintedDetail.map((mm) => `${mm.name} [${mm.kind}]`).join(', ')}`
+        : 'Agents this project minted: (none this run)',
+    ].join('\n'),
+    // WHAT THE SURVEY OBSERVED, not merely what the PRD declares. Everything else handed to
+    // this seam — paths, dependency lists, ticket titles — is a claim about the code rather
+    // than an observation of it, and the specialiser writes the project-facts paragraph that
+    // every persona inherits. Handed over WITH its caveat; see surveyLeadsBlock.
+    __SURVEY_LEADS__: spec.surveyTeamShapeBlock(survey),
+    __CODELINE_CONTEXT__: codelineContext(codelines, stories),
+    __PRD_CONFIGURATION_BLOCK__: prdConfigurationBlock,
+    // __STACK__ is deliberately ABSENT. It is a stack-fact key, and engine-prompt.js injects
+    // the ones a template declares — but only when the caller has not supplied them. Passing
+    // an empty string here would win, and starve the agent of the codeline's real facts.
+    // RENDERED FROM THE PROMPT LAYER, not written here. See lib/refusal-block.js: this text
+    // existed at three call sites in three wordings, none of them reviewable as a prompt.
+    __PREVIOUS_REFUSAL__: refusalBlock(refusal, 'roster'),
+  });
+  // spec.runClaude, like every other seam in this file. promptExec is the RUNNER handed to
+  // it, not something to call — invoking it directly threw "promptExec is not a function".
+  // I invented a call shape instead of matching the one already here, which is the third bug
+  // in this stage from that same habit.
+  //
+  // AGENTS_DIR, not LOG_DIR: seamInvocationEnv reads the invocation registry from the
+  // directory it is given, and handed the log folder it found none and resolved no ladder.
+  const seamEnv = {
+    // ATTEMPT N RUNS RUNG N-1. buildProjectRoster has always handed `attempt` to this producer
+    // and it was destructured away, so all three attempts re-ran the same model: the refusal
+    // was fed back to the one model that had just produced it. Fifth site of that same shape.
+    ...seamInvocationEnv('roster-specialiser', AGENTS_DIR,
+      { rung: Math.max(0, (Number(attempt) || 1) - 1) }),
+    EPAM_AGENT_NAME: 'roster-specialiser',
+  };
+  // The tool CHANNEL and the tool LIST travel together: granting one without the other gives
+  // an agent that quietly has nothing, and this one's whole job is to read the codeline and
+  // write a file.
+  if (seamEnv.EPAM_ALLOWED_TOOLS) seamEnv.AI_GATE_ALLOW_TOOLS = '1';
+  const ask = (text, log) => spec.runClaude(promptExec, text, path.join(LOG_DIR, log), seamEnv, { costAgent: 'roster-specialiser' });
+  // THE ROSTER IN TURNS ON A SET THAT CUTS LONG ANSWERS. A runner that declares `limits` returns at
+  // most one turn's worth of text and reports the cut answer as a success — live 2026-10-01 (AMSD-2974,
+  // codemie-web) the whole delta in one answer was cut three times and the mint refused the run. So one
+  // turn names the agents and one turn per agent writes its entry; the engine merges them. A set with
+  // no declared budget is asked once, as before.
+  const budget = require('./project-prompt-builder.js').answerBudgetChars();
+  let reply;
+  if (Number.isFinite(budget)) {
+    const { extractDeltaJson } = require('./project-roster.js');
+    const namesReply = String(await ask(prompt + renderEngineTemplate('roster-specialisation-plan', {}), 'roster-specialiser.log') || '');
+    let names = [];
+    try {
+      const m = namesReply.match(/\{[\s\S]*\}/);
+      const parsed = m ? JSON.parse(m[0]) : null;
+      names = Array.isArray(parsed && parsed.agents) ? parsed.agents.filter((n) => typeof n === 'string' && n.trim()) : [];
+    } catch { names = []; }
+    const agents = {};
+    for (const name of names) {
+      const part = String(await ask(prompt + renderEngineTemplate('roster-specialisation-one',
+        { __AGENT__: name, __BUDGET_CHARS__: String(budget) }), `roster-specialiser-${name}.log`) || '');
+      const d = extractDeltaJson(part);
+      if (d && d.agents && d.agents[name]) agents[name] = d.agents[name];
+    }
+    // WHOLE OR NOTHING: an agent the specialiser named but whose entry did not parse leaves no roster,
+    // so the attempt is refused and retried — never a roster quietly missing an agent it chose.
+    reply = names.length && Object.keys(agents).length === names.length ? JSON.stringify({ agents }) : '';
+  } else {
+    reply = await ask(prompt, 'roster-specialiser.log');
+  }
+  // THE ENGINE PERFORMS THE WRITE. The delta is the seam's ANSWER — the same delivery the
+  // prompt-builder seam uses — so the agent needs no write tool, and a rehearsal that answers
+  // from a recording or a contract stand-in delivers exactly what a live model does. Delivered
+  // by tool call, the seam was unrehearsable (a stand-in cannot write a file) and, live, three
+  // paid attempts on 2026-09-13 ended with "the agent wrote no roster". A file the agent wrote
+  // itself (the Claude Code arm may) is still accepted; the answer is written only when it did
+  // not. lib/project-roster.js composes the roster from whatever lands at outPath.
+  if (!fs.existsSync(outPath)) {
+    const { extractDeltaJson } = require('./project-roster.js');
+    const delta = extractDeltaJson(String(reply || ''));
+    if (delta) fs.writeFileSync(outPath, JSON.stringify(delta, null, 2));
+  }
+};
+
+// REVIEWED AGAINST BOTH. With only the roster a reviewer can judge plausibility; falsifying
+// "is this ancestor close" and "was inherited structure quietly changed" needs the source.
+const review = async ({ rosterPath, canonicalPath: copyPath }) => {
+  // The SEAM's own name. This announced 'roster-review' — a different seam, with a different
+  // template and a different job (certifying newly minted agents). The two would have
+  // resolved different ladders and filed their cost and KB under the wrong agent, which is
+  // the drift this file already warns about where roster-review is invoked properly.
+  process.env.EPAM_AGENT_NAME = 'project-roster-review';
+  try {
+    return await spec.reviewProjectRoster({
+      promptExec, rosterPath, canonicalPath: copyPath,
+      codelines, tickets: stories, logDir: LOG_DIR, repoPath: REPO_PATH, toolGrant,
+    });
+  } catch (err) {
+    // A review that cannot run must not read as "no defects".
+    process.stderr.write(`[mint-step] roster review FAILED: ${err && err.message}\n`);
+    return { verdict: 'review_failed', reason: String(err && err.message) };
+  }
+};
+
+  return { produce, review };
+}
+
+module.exports = { rosterSeams, codelineContext };

package/orchestrations/scripts/mint-agents-step.js

@@ -899,122 +899,17 @@ if (require.main !== module) return;
   // passed adversarial review was as likely to come back subtly wrong as to come back the
   // same, and the reviewer's own capped budget went on re-checking settled work. Only the
   // agents a blocking finding NAMES are replaced.
-  const runRosterReview = async () => {
-    // Same reason as reviewRoster: nothing was examined, so nothing may be certified.
-    if (!_mintedDetail.length) return { verdict: 'nothing_to_review', findings: [], reviewed: 0 };
-    process.env.EPAM_AGENT_NAME = 'roster-review';
-    try {
-      const liveProfiles = JSON.parse(fs.readFileSync(PROFILES_PATH, 'utf8'));
-      // THE PROJECT'S OWN PROFILES TOO. The minted agents' briefs are written here, not into the
-      // engine's canonical profiles — so passing only the latter handed the reviewer a header with
-      // a blank line under it for every agent it was asked to judge. It reported them all "empty"
-      // and blocked the roster twice, correctly about the text and wrongly about the roster.
-      let projectProfiles = {};
-      try {
-        const _pp = path.join(process.env.EPAM_PROJECT_CONFIG_DIR || '', 'agent-profiles.json');
-        projectProfiles = JSON.parse(fs.readFileSync(_pp, 'utf8'));
-      } catch { /* a project with no minted profiles yet has none to add */ }
-      return await spec.reviewRoster({
-        promptExec, minted: _mintedDetail, profiles: liveProfiles, projectProfiles,
-        codelines, tickets: stories, referencedDocs: docs,
-        logDir: LOG_DIR, repoPath: REPO_PATH, toolGrant,
-      });
-    } catch (err) {
-      // A review that cannot run must not read as "no defects" — that is the fail-open shape
-      // these gates exist to prevent.
-      process.stderr.write(`[mint-step] roster review FAILED: ${err && err.message}\n`);
-      return { verdict: 'review_failed', findings: [], reviewed: 0, error: String(err && err.message) };
-    }
-  };
-
-  const reportReview = (rv, n) => {
-    const blocking = rv.findings.filter((f) => f && f.severity === 'blocking');
-    process.stderr.write(
-      `[mint-step] roster review (cycle ${n}): ${rv.verdict} — ${rv.findings.length} finding(s), ` +
-      `${blocking.length} blocking\n`);
-    for (const f of rv.findings) {
-      process.stderr.write(`[mint-step]   [${f.severity}] ${f.agent}: ${f.claim}\n`);
-      process.stderr.write(`[mint-step]      checked: ${f.checked}\n`);
-      process.stderr.write(`[mint-step]      found:   ${f.found}\n`);
-      if (f.remedy) process.stderr.write(`[mint-step]      remedy:  ${f.remedy}\n`);
-    }
-  };
-
-  // THE CORRECTION BUDGET IS THE SEAM'S RETRY BUDGET — the same one every other seam retries on
-  // (SEAM_MAX_RETRIES / SPEC_AGENT_MAX_RETRIES, default 3) plus the first attempt. It was a
-  // literal 2: one correction, then refuse. A roster that needed two corrections was refused
-  // with the second review's findings unanswered (run 20260916T233216Z).
+  // THE REVIEW-AND-CORRECTION CYCLE is one unit (lib/roster-mint-cycle.js), so the live proof can run it on a sample mint.
   const _seamRetries = Math.max(0, parseInt(process.env.SEAM_MAX_RETRIES || process.env.SPEC_AGENT_MAX_RETRIES || '3', 10) || 0);
   const maxCycles = Number(process.env.EPAM_ROSTER_REVIEW_CYCLES || String(_seamRetries + 1));
-  let cycle = 1;
-  let review = { verdict: 'not_run', findings: [], reviewed: 0 };
-
-  while (_mintedDetail.length && cycle <= maxCycles) {
-    review = await runRosterReview();
-    const blocking = review.findings.filter((f) => f && f.severity === 'blocking');
-    reportReview(review, cycle);
-    if (!blocking.length || cycle === maxCycles) break;
-
-    // Which agents does the reviewer actually indict? A finding names one in `agent`. A
-    // finding that names nothing — or names something not in this roster — is a statement
-    // about a GAP ("no one covers this codeline"), which indicts no brief and must remove
-    // nothing. Those still feed the corrective prompt, where they read as work to add.
-    const { indicted: _indicted, retained: _retained, gaps: _gapFindings, superfluous: _superfluous } =
-      rosterLib.partitionRosterFindings(blocking, _mintedDetail);
-
-    process.stderr.write(
-      `[mint-step] cycle ${cycle}: ${blocking.length} blocking finding(s) — ` +
-      `${_indicted.length} agent(s) indicted, ${_retained.length} retained` +
-      `${_gapFindings ? `, ${_gapFindings} finding(s) name no agent (roster gaps)` : ''}` +
-      `${_superfluous && _superfluous.length ? `, ${_superfluous.length} superfluous (no replacement needed)` : ''}\n`);
-
-    // Nothing indicted and nothing to add would re-mint the same roster forever against the
-    // same findings. Stop and let the operator see them rather than burn the budget.
-    if (!_indicted.length && !_gapFindings) {
-      process.stderr.write(
-        '[mint-step]   no blocking finding names an agent in this roster — nothing to correct; ' +
-        'surfacing the findings instead of re-minting\n');
-      break;
-    }
-
-    const cleared = rosterLib.clearProjectRoster(AGENTS_DIR, PROFILES_PATH, _indicted);
-    for (const c of cleared) {
-      const isSuper = _superfluous && _superfluous.includes(c);
-      process.stderr.write(`[mint-step]   − ${c} (${isSuper ? 'superfluous — no replacement' : 'indicted, being replaced'})\n`);
-    }
-    for (const r of _retained) process.stderr.write(`[mint-step]   = ${r.name} (passed review, kept)\n`);
-
-    // Superfluous agents are removed without replacement: their work is already covered by
-    // retained roles. Telling the minter to "cover EVERYTHING" for a superfluous role causes it
-    // to create a new catchall that re-introduces the overlap the reviewer just flagged.
-    const _replacedForMint = _mintedDetail.filter(
-      (m) => _indicted.includes(m.name) && !(_superfluous && _superfluous.includes(m.name)));
-    const _superfluousForMint = _mintedDetail.filter(
-      (m) => _superfluous && _superfluous.includes(m.name));
-
-    const remint = await spec.mintProjectAgents({
-      promptExec, tickets: stories, referencedDocs: docs, declaredDependencies: deps,
-      codelines, toolGrant, profilesPath: PROFILES_PATH, agentsDir: AGENTS_DIR,
-      logDir: LOG_DIR, repoPath: REPO_PATH, correctiveFindings: blocking,
-      retainedAgents: _retained,
-      replacedAgents: _replacedForMint,
-      superfluousAgents: _superfluousForMint,
-    });
-    // The next review sees the WHOLE roster, not just the replacements: a new brief can
-    // duplicate or contradict a retained one, and only a review of both would catch it.
-    _mintedDetail = [..._retained, ...remint.minted];
-    _mintedNames = _mintedDetail.map((m) => m.name);
-    fs.writeFileSync(path.join(LOG_DIR, `agent-mint-cycle${cycle + 1}.json`), JSON.stringify(remint, null, 2));
-    for (const m of remint.minted) {
-      const tag = m.kind === 'investigator' ? `investigator:${m.codeline || '(no codeline!)'}` : 'implementer';
-      process.stderr.write(`[mint-step]   + [${tag}] ${m.name} — ${m.rationale}\n`);
-    }
-
-
-    cycle += 1;
-  }
-
-  review.cycles = cycle;
+  const _cycled = await require('./lib/roster-mint-cycle.js').reviewAndCorrectRoster({
+    spec, rosterLib, promptExec, stories, docs, deps, codelines, toolGrant,
+    profilesPath: PROFILES_PATH, agentsDir: AGENTS_DIR, logDir: LOG_DIR, repoPath: REPO_PATH,
+    projectConfigDir: process.env.EPAM_PROJECT_CONFIG_DIR || '', mintedDetail: _mintedDetail, maxCycles,
+    log: (m) => process.stderr.write(`[mint-step] ${m}\n`),
+  });
+  _mintedDetail = _cycled.mintedDetail; _mintedNames = _cycled.mintedNames;
+  const review = _cycled.review;
   fs.writeFileSync(path.join(LOG_DIR, 'roster-review.json'), JSON.stringify(review, null, 2));
 
   // THE REVIEW NOT RUNNING IS AS SERIOUS AS THE REVIEW FAILING THE ROSTER.
@@ -1352,9 +1247,7 @@ if (require.main !== module) return;
       projectContext: require('./lib/project-prompt-builder.js').useCaseContext({ projectConfigDir, stories, codelines }),
       // The same text the reviewer is handed, so the generator and its judge see one context.
       codelineContext: _codelineContext,
-      mintedRoles: _projectRoles.length
-        ? _projectRoles.map((m) => `- ${m.name} [${m.kind}] — ${m.rationale || ''}`).join('\n')
-        : '(none minted this run)',
+      mintedRoles: require('./lib/project-prompt-builder.js').mintedRolesBlock(_projectRoles),
       // THE BUILDER RUNS AT ITS OWN SEAM, with the grants that seam declares.
       //
       // It passed {} as the environment, so it inherited whatever the mint process happened to

package/orchestrations/scripts/refresh-project-prompts.js

@@ -90,7 +90,7 @@ async function main() {
       attempts: Number(process.env.EPAM_PROMPT_ATTEMPTS || 5),
       projectContext: builder.useCaseContext({ projectConfigDir, stories, codelines }),
       codelineContext,
-      mintedRoles: roles.length ? roles.map((m) => `- ${m.name} [${m.kind}] — ${m.rationale || ''}`).join('\n') : '(none minted this run)',
+      mintedRoles: builder.mintedRolesBlock(roles),
       ...calls,
       log: (m) => { lines.push(m); process.stderr.write(`[${codeline}] ${m}\n`); },
     });

package/orchestrations/scripts/spec-mode-runner.js

@@ -3777,6 +3777,26 @@ const TOOL_PROJECT_AGENTS = {
  * field collected and never shown is inert — this pipeline has produced several — so the
  * rendering is here, where a test executes it.
  */
+/** What the survey says about a codeline that a standing role may be told: whether work reaches it. Not what it found. */
+function surveyTeamShapeLine(c) {
+  return `- ${c.codeline}: ${c.state}`;
+}
+
+/** The survey as the TEAM's shape — which codelines the work reaches and the kinds of role each needs — for the specialiser. */
+function surveyTeamShapeBlock(estateSurvey) {
+  const sv = estateSurvey && estateSurvey.ran === true && Array.isArray(estateSurvey.codelines) ? estateSurvey : null;
+  if (!sv) return '';
+  const lines = sv.codelines.filter(Boolean).map(surveyTeamShapeLine);
+  if (!lines.length) return '';
+  const inv = (sv.recommendedInvestigators || []).map((r) => r.codeline).filter(Boolean);
+  const wr = (sv.recommendedWriters || []).map((r) => r.codeline).filter(Boolean);
+  return ['WHICH CODELINES THE WORK REACHES, as a survey of the repositories reported (work_found / no_work_found /',
+    'not_investigated). You are not told what it found there: a persona is kept with the codeline and serves every later',
+    'ticket on it, so it is specialised to the codeline, never to this work.', '', ...lines,
+    ...(inv.length ? ['', `Codelines that need their own investigator: ${inv.join(', ')}`] : []),
+    ...(wr.length ? [`Codelines that need work written: ${wr.join(', ')}`] : []), ''].join('\n');
+}
+
 function surveyLineFor(c) {
   const areas = c.surfaces && c.surfaces.length ? ` — areas: ${c.surfaces.join(', ')}` : '';
   const read = c.filesRead && c.filesRead.length
@@ -3854,40 +3874,16 @@ async function mintProjectAgents({
     }
   }
 
-  const ticketBlock = (Array.isArray(tickets) ? tickets : []).map((t) => {
-    const comps = Array.isArray(t.components) && t.components.length ? `\nComponents: ${t.components.join(', ')}` : '';
-    // THE LINK IS EVIDENCE EVEN WHEN THE FETCH FAILED. Live 2026-08-07: both linked documents
-    // came back empty, so they were dropped entirely — and the URLs themselves named the
-    // vendor the tickets never mentioned. The mint then invented a different one.
-    const links = (Array.isArray(t.ticketLinks) ? t.ticketLinks : [])
-      .map((l) => (typeof l === 'string' ? l : (l && l.url)))
-      .filter(Boolean);
-    const linkLine = links.length ? `\n  Links on this ticket: ${links.join(' , ')}` : '';
-    return `- ${t.jiraKey || t.id || ''}: ${t.title || ''}${comps}\n  ${String(t.description || '').replace(/\s+/g, ' ')}${linkLine}`;
-  }).join('\n');
+  // THE WORK'S SHAPE, NOT ITS WORDS. The ticket's key, title, description, components and links were the first thing the
+  // proposer read, and every roster it wrote was named after them — "accessible-toast-engineer", "site-toast-integration-
+  // engineer" (live 2026-10-24, with a rule saying ZERO references in the same prompt). A roster is kept with the codeline and
+  // reused for every later story on it, so the proposer is told how much work reaches these codelines and nothing of what
+  // it is about. Which codelines the work reaches was settled by discovery: they are the codelines listed.
+  const _tickets = Array.isArray(tickets) ? tickets : [];
+  const workShapeBlock = `${_tickets.length} ticket(s) from the tracker reach the codelines listed below. You are not told what the tickets ask for,
+on purpose: the roster you propose is kept with these codelines and serves every later ticket on them, so each role is named
+and briefed for ITS CODELINE — its stack, structure, conventions, how it is built and tested — never for one piece of work.`;
 
-  // The vendor's own published contract, quoted verbatim by the link agent. This is the
-  // sharpest signal about which domains this work actually spans.
-  // QUOTES OR THE DOCUMENT ITSELF.
-  //
-  // This required d.quotes, which only the ticket-link AGENT produces — it runs in the spec
-  // pass, after this. fetchTicketDocuments returns {url, fetchStatus, path} and no quotes, so
-  // every successfully fetched document was filtered straight back out: 25KB of vendor
-  // documentation retrieved, named the real product, and reached the proposer as nothing.
-  // Verified before the run rather than discovered by it.
-  const docBlock = (Array.isArray(referencedDocs) ? referencedDocs : [])
-    .filter((d) => d && d.fetchStatus === 'fetched')
-    .map((d) => {
-      if (Array.isArray(d.quotes) && d.quotes.length) {
-        return `- ${d.url}\n${d.quotes.map((q) => `    "${String(q).replace(/\s+/g, ' ')}"`).join('\n')}`;
-      }
-      // Not truncated: this is the authoritative statement of what the work involves, and a
-      // cut copy is how a proposer ends up inferring the rest.
-      let body = typeof d.body === 'string' ? d.body : '';
-      if (!body && d.path) { try { body = fs.readFileSync(d.path, 'utf8'); } catch { body = ''; } }
-      return body ? `- ${d.url}\n${body}` : `- ${d.url} (retrieved, no readable text)`;
-    })
-    .join('\n\n');
 
   // WHAT THE CODELINE DECLARES IT USES. Ground truth about the stack, and the correction for
   // a specific live failure: on 2026-08-07 the tickets said only "CMS", both linked documents
@@ -4029,7 +4025,8 @@ async function mintProjectAgents({
   // ticket, its documents, the declared dependencies — is a claim about the code rather than
   // an observation of it, which is how briefs came to name modules that do not exist.
   const _sv = estateSurvey && Array.isArray(estateSurvey.codelines) ? estateSurvey : null;
-  const _svLines = _sv ? _sv.codelines.map(surveyLineFor) : [];
+  // its surfaces, files and evidence are what the survey found for THIS ticket — a brief that names them is geared to it
+  const _svLines = _sv ? _sv.codelines.filter(Boolean).map(surveyTeamShapeLine) : [];
   const surveyBlock = _svLines.length
     ? ['WHAT A SURVEY OF THESE REPOSITORIES REPORTED. These are LEADS, not settled facts.',
        '',
@@ -4050,11 +4047,9 @@ async function mintProjectAgents({
        ...(_sv.recommendedInvestigators.length
          ? ['SEPARATELY — and this is a recommendation about the TEAM, not something discovered',
             'about the code: a survey of the estate suggests these codelines need their own',
-            'investigator. Propose one per codeline named here, with the stated focus:',
+            'investigator. Propose one per codeline named here, briefed on that codeline:',
             '',
-            ..._sv.recommendedInvestigators.map((r) =>
-              `- ${r.codeline}: focus on ${String(r.focus || '').replace(/\s+/g, ' ')}` +
-              `${r.why ? ` (because ${String(r.why).replace(/\s+/g, ' ')})` : ''}`),
+            ..._sv.recommendedInvestigators.map((r) => `- ${r.codeline}`),
             '']
          : []),
        // THE OTHER HALF OF THE TEAM, WHICH THIS PROMPT NEVER MENTIONED.
@@ -4072,9 +4067,7 @@ async function mintProjectAgents({
             'work WRITTEN, not merely read. An investigator cannot change code; every story is',
             'assigned to an implementer, so propose at least one implementer that can build this:',
             '',
-            ..._sv.recommendedWriters.map((r) =>
-              `- ${r.codeline}: must be able to write ${String(r.focus || '').replace(/\s+/g, ' ')}` +
-              `${r.why ? ` (because ${String(r.why).replace(/\s+/g, ' ')})` : ''}`),
+            ..._sv.recommendedWriters.map((r) => `- ${r.codeline}`),
             '']
          : [])].join('\n')
     : '';
@@ -4133,8 +4126,8 @@ async function mintProjectAgents({
 
   const prompt = `${correctiveBlock}${replacedBlock}${superfluousBlock}${retainedBlock}${existingRosterBlock}${surveyBlock}${vendorClaimRule}${testOwnershipRule}${basePrompt}
 
-THE WORK THIS PROJECT HAS BEEN ASKED TO DO (real tickets from the tracker):
-${ticketBlock || '- (no tickets available)'}
+THE WORK THAT REACHES THESE CODELINES:
+${workShapeBlock}
 
 ${depBlock ? `WHAT THIS CODELINE DECLARES IT DEPENDS ON (from its own manifest — ground truth
 about the stack, not inference from the ticket text). Where a ticket names a category
@@ -4143,10 +4136,7 @@ around a product that does not appear here:
 ${depBlock}
 
 ` : ''}
-${docBlock ? `DOCUMENTATION LINKED ON THESE TICKETS (fetched, quoted verbatim — the vendor's published contract):
-${docBlock}
-
-` : ''}${codelineBlock}
+${codelineBlock}
 ${toolGrant ? renderEngineTemplate('roster-tool-grant', { __TOOL_GRANT__: toolGrant }) : `You have NO tools on this call — you cannot open these
 repositories. Reason only from what is written above, and say in the rationale when a claim
 rests on documentation rather than on this codebase.`}
@@ -4488,7 +4478,7 @@ const TOOL_ROSTER_REVIEW = {
           required: ['name', 'outlivesTicket', 'why'],
           properties: {
             name: { type: 'string', description: 'The minted role, named exactly as in the roster.' },
-            outlivesTicket: { type: 'boolean', description: 'true only when this role — its name and its brief — would serve a story on this codeline about something OTHER than the current ticket: named for the kind of engineer/investigator and the codeline, briefed on the codeline, not on this ticket\'s subject, components or files (except as marked examples).' },
+            outlivesTicket: { type: 'boolean', description: 'true only when this role\'s name and brief refer to the current ticket in NO way — not its key, title, subject, components, requirements or files, not even as an example — and would serve a story on this codeline about something else. Any such reference, in any wording, makes it false.' },
             why: { type: 'string', description: 'Quote the words that gear the role to the ticket, or say what makes it the codeline\'s.' },
           },
         },
@@ -4910,7 +4900,7 @@ function rolesOutliveTicketFindings(part) {
     agent: String(r.name), severity: 'blocking', claim: String(r.why || '(the reviewer gave no words)'),
     checked: 'whether this role, as named and briefed, would serve a story on its codeline about something other than the current ticket',
     found: 'minted for the ticket in scope, not for the codeline it is kept with',
-    remedy: 'a role named for its kind of work and its codeline, briefed on the codeline — its stack, conventions and how to verify there — naming the current ticket only as a marked example',
+    remedy: 'a role named for its kind of work and its codeline, briefed on the codeline — its stack, conventions and how to verify there — never naming the current ticket, not even as an example',
   }));
 }
 
@@ -6691,46 +6681,6 @@ function prescriptionMissingSource(sites) {
  * survey that did not run, a codeline it never covered, or one it put out of scope — because a
  * fabricated starting point is worse than none.
  */
-/**
- * surveyLeadsBlock(estateSurvey) — what a survey of the repositories OBSERVED, with its caveat.
- *
- * THE OBSERVATION HALF, SEPARATED FROM THE INSTRUCTION HALF. mintProjectAgents builds a block that
- * mixes the survey's findings with instructions to PROPOSE roles and investigators. Those
- * instructions are about staffing a team and mean nothing to a seam that is specialising personas,
- * but the findings mean everything to it: they are the only input in the whole roster stage
- * derived from opening the repositories.
- *
- * WHY THIS EXISTS AT ALL. estateSurvey was consumed only by mintProjectAgents, so the seam that
- * chooses WHICH agents to make saw the repositories and the seam that decides WHAT THEY BELIEVE
- * did not. The specialiser was handed codeline names, paths and dependency lists, and asked to
- * write the project-facts paragraph that goes into every persona. Live 2026-09-08: it wrote that
- * this repo colocates .spec.tsx beside the component, the roster review refuted it (338 of 368
- * files are under __tests__/), and three attempts escalating to opus-4-8 cost $8.23 plus $3.47 of
- * review — to establish something `find` answers instantly, and which the survey had already read.
- *
- * THE CAVEAT IS PART OF THE EVIDENCE, never separable from it. A survey line handed over bare is
- * worse than none: bare is exactly how "as this repo already does" became an instruction inherited
- * by every agent. A survey has been wrong before — 2026-08-08 it reported a repository contained
- * no reference to a package its own source uses in twenty files.
- */
-function surveyLeadsBlock(estateSurvey) {
-  const sv = estateSurvey && estateSurvey.ran === true && Array.isArray(estateSurvey.codelines)
-    ? estateSurvey : null;
-  if (!sv) return '';
-  const lines = sv.codelines.filter(Boolean).map(surveyLineFor);
-  if (!lines.length) return '';
-  return [
-    'WHAT A SURVEY OF THESE REPOSITORIES REPORTED. These are LEADS, not settled facts.',
-    '',
-    'This was read from the repositories before the roster existed. It has been wrong before, so',
-    'treat every line below as what the survey BELIEVES. Do NOT restate any of it in an agent brief',
-    'as established, verified or confirmed — a brief is inherited whole and re-checked by nothing,',
-    'so a wrong lead written as a fact becomes an instruction every agent obeys.',
-    '',
-    ...lines,
-    '',
-  ].join('\n');
-}
 
 /**
  * configSurfaceBlock — the configuration files this codeline carries that govern what its code is
@@ -11216,7 +11166,7 @@ module.exports = {
   buildRosterReviewPrompt,
   buildSurveyPrompt,
   surveyLineFor,
-  surveyLeadsBlock,
+  surveyTeamShapeBlock,
   reconcileMintTally,
   SURVEY_STATES,
   TOOL_ROSTER_REVIEW,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "amsd-pipeline-shared",
-  "version": "0.5.41",
+  "version": "0.5.43",
   "description": "The AMSD pipeline's shared components, one source for the bash pipeline and its Claude workflows: the model-call gateway (llm-handler.sh — retry, ladder, self-heal, cost) and the libraries it runs.",
   "license": "UNLICENSED",
   "bin": {