amsd-pipeline-shared 0.5.13 → 0.5.15

package/orchestrations/prompts/templates/team-lead-review.json

@@ -1,7 +1,7 @@
 {
   "id": "team-lead-review",
   "layer": "project",
-  "version": 3,
+  "version": 4,
   "description": "The code reviewer: judges a story change against its criteria and emits a verdict.",
   "$why": [
     "MIGRATED OUT OF team-lead-review.sh ON 2026-08-13, byte-identical (3827 bytes).",
@@ -10,7 +10,8 @@
     "NO PROJECT FACT BELONGS HERE. Under the target design a mint-time agent generates each project prompt using this template as its guide.",
     "v2, 2026-08-13: the scan_secrets example named a CLIENT environment variable. A project fact in a generic template becomes wrong output for every other project once a mint-time agent generates project prompts from it.",
     "2026-08-19: see code-review-cycle — unevidenced issues are discarded by code-review-json.py, so this seam must ask for evidence too.",
-    "2026-08-19: this seam is the ONLY reviewer the pipeline executes, and it received no prior verdict and no iteration number — zero occurrences of PRIOR or __ITERATION__ in team-lead-review.sh. A live brownfield run run 2 it approved a story whose blocker it had raised and which had not changed since; the engine detected that and called an escalation function that does not exist. It never changed its mind — it was never told it had a mind to change. The history was already append-only in code-reviews.jsonl."
+    "2026-08-19: this seam is the ONLY reviewer the pipeline executes, and it received no prior verdict and no iteration number — zero occurrences of PRIOR or __ITERATION__ in team-lead-review.sh. A live brownfield run run 2 it approved a story whose blocker it had raised and which had not changed since; the engine detected that and called an escalation function that does not exist. It never changed its mind — it was never told it had a mind to change. The history was already append-only in code-reviews.jsonl.",
+    "v4 (operator, 2026-10-21: \"It should not run whole suite … the writer should make tests and we run those tests\"): the reviewer runs only the story's own test files — run 11's re-review ran cx-shared's whole jest suite (2,170 files) and the session was OOM-killed."
   ],
   "placeholders": [
     "__ESTIMATION_ASSESSMENT__",
@@ -32,7 +33,7 @@
     "__VC_BLOCK__",
     "__STORY_ACS__"
   ],
-  "body": "REVIEW TASK: Story __STORY_ID__ — __STORY_TITLE__\n\nDESCRIPTION:\n__STORY_DESC__\n\n__STORY_ACS____VC_BLOCK____ESTIMATION_ASSESSMENT__\n__UNCOVERED_VC_BLOCK__\n__FIX_ANALYSIS_BLOCK__\n__BLOCKER_DISCIPLINE__\n\nRELEVANT FILES (fix files + the reproducing test the pipeline shipped — review BOTH): __STORY_FILES__ __TEST_FILES__\n\nGIT DIFF (recent changes):\n```diff\n__STORY_DIFF__\n```\n\nPROJECT ROOT: __PROJECT_ROOT__\n__CODEGRAPH_TOOL_BLOCK__\n\nCREDENTIALS. Call scan_secrets with the diff above before you finish. It reports values that\nhave been PASTED INTO the code — a quoted, long, high-entropy literal assigned to a\ncredential-shaped name. It deliberately does NOT report references (an identifier, a member\nexpression, a process.env read), because those are the correct practice: a pasted key is always\na literal, so nothing real is missed by ignoring them.\n\n  scan_secrets(diff=\"<the GIT DIFF above>\")\n\nJudge what it returns; it does not block anything. A finding is a blocker — a credential in\nsource is not fixable after the fact once committed. An empty result is not proof of safety on\nits own, so if the diff introduces configuration you can still say so in your own words.\n\nThis check used to run at commit time and matched `name: value` on shape alone. On 2026-08-09\nit refused a correct commit for `management_token: SOME_SERVICE_API_TOKEN` — an\nenvironment-derived identifier — and had never caught a real leak. It is yours now because you\nhave the diff and can tell the two apart.\n\nReview the implementation against each acceptance criterion above.\nCheck: TypeScript strict compliance, error handling, security (OWASP).\n__TEST_OWNERSHIP__\n\nCONCISION & REUSE (blocker-level checks):\n- If the change addresses the symptom but NOT the prescribed root cause above (e.g. adds new code paths the bug never reaches), that is a 'blocker' — request changes.\n- If a MORE CONCISE change would achieve the SAME criteria with the SAME coverage, request changes and name it. A shorter change that leaves a criterion unmet or a behaviour untested is not more concise — it is incomplete.\n- If the diff hand-rolls logic that an EXISTING function/helper already provides (verify with the tool above), that is a 'blocker' — request changes and name the helper to reuse instead.\n- Do NOT approve an over-engineered fix just because it satisfies the AC wording.\n\nTEST COVERAGE VERIFICATION (grounded, not a visual skim — found live 2026-08-03,\nObserved live: the reviewer claimed 2 of 3 required test scenarios were missing,\nTWICE in a row, against a diff that unambiguously contained all 3 as clearly-\nnamed `it(...)` blocks — a real, reproducible failure to verify a claim the\ntools below could have confirmed in one call):\n- Before flagging ANY acceptance-criteria test scenario as missing or absent, use\n  the search tool to grep the diff above (or read_file on the test file under\n  PROJECT_ROOT) for an `it(`/`test(` block whose name or body plausibly covers\n  that scenario. A large diff is easy to skim past a matching block — search for\n  it, do not judge from a visual read alone.\n- If your search finds a plausible match, do NOT flag that scenario as missing —\n  if the test's assertions are wrong or incomplete, say so specifically (quote\n  the test name and what it fails to assert); 'missing' and 'inadequate' are\n  different findings and must not be conflated.\n- If your search finds nothing, name the exact search you ran (tool + query) in\n  the issue description, so a genuinely absent test is distinguishable from an\n  unverified guess.\nDo NOT read from external URLs.\n__LEARNED_RULES_BLOCK__\n__PROJECT_TOOLS_BLOCK__\n\nRespond with ONLY a JSON object (no markdown fences):\n{\"verdict\":\"approved\",\"rating\":9,\"unmet\":[],\"issues\":[],\"summary\":\"...\"}\n  OR\n{\"verdict\":\"changes_requested\",\"rating\":6,\"unmet\":[\"<each criterion not met, and what would meet it>\"],\"issues\":[{\"severity\":\"blocker|major|minor\",\"file\":\"...\",\"line\":0,\"description\":\"...\",\"suggestedFix\":\"...\"}],\"summary\":\"...\"}\n\nA 'blocker' issue MUST be fixed before merge. 'major' should be fixed. 'minor' is optional.\n\nEvery issue MUST carry an `evidence` field: the exact thing you READ that establishes it — `<path>:<line>` you opened, or the command you ran and what it returned. Not a restatement of the claim, not a plan reference: what you looked at. An issue without evidence is DISCARDED before it reaches anyone, so an unsupported finding is worse than no finding — it costs you the issue. If a claim is about a library's API, the evidence is that library's installed types or source in this repository, and the installed contract beats the plan.\n\n\n__PRIOR_REVIEW__\nCONSISTENCY WITH YOUR OWN PREVIOUS VERDICTS\n\nIf you raised a blocker on an earlier iteration and the code that caused it has not changed, that\nblocker still stands: raise it again, and do NOT approve. Dropping a finding is a decision that the\nfinding was wrong — if you now believe that, say so explicitly and give the evidence that changed\nyour mind. Silence is not resolution, and an approval that follows an unresolved blocker is the one\noutcome this pipeline cannot detect for itself.\n\nIf the code HAS changed, judge the change on its merits: a previous blocker is not a permanent one.\n\n\nACCOUNT FOR EVERY VERIFICATION CRITERION. Alongside the verdict, emit `vcAssessment`: one entry per criterion listed above, `{\"criterion\":\"<the criterion, restated>\",\"met\":true|false,\"evidence\":\"<path>:<line> you opened, or the command you ran and what it returned>\"}`. An approval that names no criterion cannot be checked by anyone afterwards. Do NOT approve while marking a criterion unmet — that contradiction is rejected automatically and costs you the review.",
+  "body": "REVIEW TASK: Story __STORY_ID__ — __STORY_TITLE__\n\nDESCRIPTION:\n__STORY_DESC__\n\n__STORY_ACS____VC_BLOCK____ESTIMATION_ASSESSMENT__\n__UNCOVERED_VC_BLOCK__\n__FIX_ANALYSIS_BLOCK__\n__BLOCKER_DISCIPLINE__\n\nRELEVANT FILES (fix files + the reproducing test the pipeline shipped — review BOTH): __STORY_FILES__ __TEST_FILES__\n\nRUNNING TESTS. Run ONLY the story's own tests — the test files listed above — with the project's test runner given those paths. Never run the whole suite: the pipeline's gates run it, and a whole-suite run inside your session is killed for memory before you can answer.\n\nGIT DIFF (recent changes):\n```diff\n__STORY_DIFF__\n```\n\nPROJECT ROOT: __PROJECT_ROOT__\n__CODEGRAPH_TOOL_BLOCK__\n\nCREDENTIALS. Call scan_secrets with the diff above before you finish. It reports values that\nhave been PASTED INTO the code — a quoted, long, high-entropy literal assigned to a\ncredential-shaped name. It deliberately does NOT report references (an identifier, a member\nexpression, a process.env read), because those are the correct practice: a pasted key is always\na literal, so nothing real is missed by ignoring them.\n\n  scan_secrets(diff=\"<the GIT DIFF above>\")\n\nJudge what it returns; it does not block anything. A finding is a blocker — a credential in\nsource is not fixable after the fact once committed. An empty result is not proof of safety on\nits own, so if the diff introduces configuration you can still say so in your own words.\n\nThis check used to run at commit time and matched `name: value` on shape alone. On 2026-08-09\nit refused a correct commit for `management_token: SOME_SERVICE_API_TOKEN` — an\nenvironment-derived identifier — and had never caught a real leak. It is yours now because you\nhave the diff and can tell the two apart.\n\nReview the implementation against each acceptance criterion above.\nCheck: TypeScript strict compliance, error handling, security (OWASP).\n__TEST_OWNERSHIP__\n\nCONCISION & REUSE (blocker-level checks):\n- If the change addresses the symptom but NOT the prescribed root cause above (e.g. adds new code paths the bug never reaches), that is a 'blocker' — request changes.\n- If a MORE CONCISE change would achieve the SAME criteria with the SAME coverage, request changes and name it. A shorter change that leaves a criterion unmet or a behaviour untested is not more concise — it is incomplete.\n- If the diff hand-rolls logic that an EXISTING function/helper already provides (verify with the tool above), that is a 'blocker' — request changes and name the helper to reuse instead.\n- Do NOT approve an over-engineered fix just because it satisfies the AC wording.\n\nTEST COVERAGE VERIFICATION (grounded, not a visual skim — found live 2026-08-03,\nObserved live: the reviewer claimed 2 of 3 required test scenarios were missing,\nTWICE in a row, against a diff that unambiguously contained all 3 as clearly-\nnamed `it(...)` blocks — a real, reproducible failure to verify a claim the\ntools below could have confirmed in one call):\n- Before flagging ANY acceptance-criteria test scenario as missing or absent, use\n  the search tool to grep the diff above (or read_file on the test file under\n  PROJECT_ROOT) for an `it(`/`test(` block whose name or body plausibly covers\n  that scenario. A large diff is easy to skim past a matching block — search for\n  it, do not judge from a visual read alone.\n- If your search finds a plausible match, do NOT flag that scenario as missing —\n  if the test's assertions are wrong or incomplete, say so specifically (quote\n  the test name and what it fails to assert); 'missing' and 'inadequate' are\n  different findings and must not be conflated.\n- If your search finds nothing, name the exact search you ran (tool + query) in\n  the issue description, so a genuinely absent test is distinguishable from an\n  unverified guess.\nDo NOT read from external URLs.\n__LEARNED_RULES_BLOCK__\n__PROJECT_TOOLS_BLOCK__\n\nRespond with ONLY a JSON object (no markdown fences):\n{\"verdict\":\"approved\",\"rating\":9,\"unmet\":[],\"issues\":[],\"summary\":\"...\"}\n  OR\n{\"verdict\":\"changes_requested\",\"rating\":6,\"unmet\":[\"<each criterion not met, and what would meet it>\"],\"issues\":[{\"severity\":\"blocker|major|minor\",\"file\":\"...\",\"line\":0,\"description\":\"...\",\"suggestedFix\":\"...\"}],\"summary\":\"...\"}\n\nA 'blocker' issue MUST be fixed before merge. 'major' should be fixed. 'minor' is optional.\n\nEvery issue MUST carry an `evidence` field: the exact thing you READ that establishes it — `<path>:<line>` you opened, or the command you ran and what it returned. Not a restatement of the claim, not a plan reference: what you looked at. An issue without evidence is DISCARDED before it reaches anyone, so an unsupported finding is worse than no finding — it costs you the issue. If a claim is about a library's API, the evidence is that library's installed types or source in this repository, and the installed contract beats the plan.\n\n\n__PRIOR_REVIEW__\nCONSISTENCY WITH YOUR OWN PREVIOUS VERDICTS\n\nIf you raised a blocker on an earlier iteration and the code that caused it has not changed, that\nblocker still stands: raise it again, and do NOT approve. Dropping a finding is a decision that the\nfinding was wrong — if you now believe that, say so explicitly and give the evidence that changed\nyour mind. Silence is not resolution, and an approval that follows an unresolved blocker is the one\noutcome this pipeline cannot detect for itself.\n\nIf the code HAS changed, judge the change on its merits: a previous blocker is not a permanent one.\n\n\nACCOUNT FOR EVERY VERIFICATION CRITERION. Alongside the verdict, emit `vcAssessment`: one entry per criterion listed above, `{\"criterion\":\"<the criterion, restated>\",\"met\":true|false,\"evidence\":\"<path>:<line> you opened, or the command you ran and what it returned>\"}`. An approval that names no criterion cannot be checked by anyone afterwards. Do NOT approve while marking a criterion unmet — that contradiction is rejected automatically and costs you the review.",
   "seams": [
     "team-lead-review"
   ],

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

@@ -57,7 +57,10 @@ async function main() {
     process.env.EPAM_CODELINE_ID = codeline;
     process.env.EPAM_PROJECT_CONFIG_DIR = projectConfigDir;
     process.env.PRD_FILE = slice;
+    // A CODELINE NEVER PROVISIONED HAS NOTHING TO REFRESH: its first run builds its set. Building it here would be that run's
+    // whole provisioning, paid for outside a run.
     const restored = builder.restoreMinted({ projectConfigDir, codeline });
+    if (!restored) { report.push({ codeline, restored, skipped: 'no recorded agents and prompts for this codeline', rebuilt: [], kept: 0 }); continue; }
     const roles = lib('project-roster.js').mintedFromRegistries(projectConfigDir);
     const codelines = [{ name: o.codeline, path: o.path }];
     const codelineContext = lib('codeline-context.js').buildCodelineContext({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "amsd-pipeline-shared",
-  "version": "0.5.13",
+  "version": "0.5.15",
   "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": {