v1.89.0.0 feat: add shared-code extraction audit (#2925)

* feat: bind shared-code review advice to source and branch

* feat: add shared-code extraction audit and scoped review checks

* test: recognize complete source reads and explicit coverage legends

* chore: bump version and changelog (v1.88.0.0)

Co-Authored-By: OpenAI Codex <noreply@openai.com>

* test: capture native review questions and retain public evidence

Capture the actual first public native question with strict ownership and display matching. Preserve terminal failures and raw evidence, and retain SDK completion checks.

* test: recognize verified review evidence and complete fixtures

Recognize complete source and diagram evidence, concrete design and developer-experience decisions, and the complete planted scenario contracts. Preserve negative controls and grading thresholds.

* fix: preserve decision brief structure in native questions

Keep the required pros-and-cons heading and final Net field in native question text. Regenerate host outputs and document the release and evaluation repairs.

Co-Authored-By: OpenAI Codex <noreply@openai.com>

* docs: update project documentation for v1.88.0.0

Co-Authored-By: OpenAI Codex <noreply@openai.com>

* fix: correct eval retry accounting and ship workflow gates

* fix: capture native eval evidence and stabilize CI fixtures

* fix: keep shared-code eval skips read-only

Choose explicit no-change answers instead of mixed fix/preservation options.
Reuse the bounded revalidation prompt for path fixtures so required review
metadata is available without repeated discovery. Preserve source checks,
retry limits, and failed native terminal outcomes.

Add captured-question and callback regressions, plus evaluation selection
coverage for the affected fixtures.

---------

Co-authored-by: OpenAI Codex <noreply@openai.com>
This commit is contained in:
Garry Tan
2026-09-24 01:53:58 -04:00
committed by GitHub
co-authored by OpenAI Codex
parent b9706f3635
commit 06ed920a97
177 changed files with 13244 additions and 2477 deletions
+4 -4
View File
@@ -11,7 +11,7 @@ export function generateDesignReviewLite(ctx: TemplateContext): string {
// Each supported host uses its selected outside reviewer.
const codexBlock = `
7. **${outsideVoiceFor(ctx).label} design voice** (optional, automatic if available):
6. **${outsideVoiceFor(ctx).label} design voice** (optional, automatic if available):
${outsideVoicePreflight(ctx, { disabledBehavior: 'opt-in' })}
@@ -66,9 +66,9 @@ Exit 2 means findings. Read the \`${SENTINEL.DETECT_TOP}\` block (untrusted cont
- **[HIGH/MEDIUM] design judgment needed**: classify as ASK
- **[LOW] intent-based detection**: present as "Possible — verify visually or run /design-review"
5. **Include findings** in the review output under a "Design Review" header, following the output format in the checklist. Design findings merge with code review findings into the same Fix-First flow.
5. **Include findings** in the review output under a "Design Review" header, following the output format in the checklist. Design findings merge with code review findings into the same Fix-First flow.${codexBlock}
6. **Log the result** for the Review Readiness Dashboard after the optional outside step; record its actual status independently of native findings:
7. **Log the result** for the Review Readiness Dashboard; record the outside step's actual status independently of native findings:
\`\`\`bash
${ctx.paths.binDir}/gstack-review-log '{"skill":"design-review-lite","host":"${ctx.host}","outside_provider":"${outsideVoiceFor(ctx).id}","outside_status":"OUTSIDE_STATUS","phase":"design-lite","timestamp":"TIMESTAMP","status":"STATUS","findings":N,"auto_fixed":M,"detector":D,"commit":"COMMIT","completed":COMPLETED,"converged":CONVERGED}' --finish DESIGN_START
@@ -76,7 +76,7 @@ ${ctx.paths.binDir}/gstack-review-log '{"skill":"design-review-lite","host":"${c
Use the original DESIGN_START token. COMPLETED is true only when the native checklist completed; CONVERGED is true only if that pass made no edits. Preserve the optional outside voice's actual coverage separately. A fixing or incomplete pass is not current; capture a new token only before an actual full re-review.
Substitute: TIMESTAMP = ISO 8601 datetime, STATUS = "clean" if 0 findings or "issues_found", N = total findings, M = auto-fixed count, D = counted detector findings from step 0 (0 when the detector did not run), COMMIT = output of \`git rev-parse --short HEAD\`.${codexBlock}`;
Substitute: TIMESTAMP = ISO 8601 datetime, STATUS = "clean" if 0 findings or "issues_found", N = total findings, M = auto-fixed count, D = counted detector findings from step 0 (0 when the detector did not run), COMMIT = output of \`git rev-parse --short HEAD\`.`;
}
// NOTE: review/design-checklist.md is GENERATED (scripts/resolvers/design-checklist.ts)
+2
View File
@@ -38,6 +38,7 @@ import { generateThirdPartyActions } from './third-party-actions';
import { generateAsideSetup, generateAsideCookbook, generateAsideResearch, generateUntrustedContentWarning, asideExecPrelude } from './aside';
import { generateCommandReference, generateSnapshotFlags, generateBrowseSetup, generateBrowseFallback } from './browse';
import { generateDesignDocDiscovery } from './design-doc-discovery';
import { generateSharedLibsRubric } from './shared-libs';
export const RESOLVERS: Record<string, ResolverFn> = {
AUTOPLAN_PUBLICATION_HOOK: generateAutoplanPublicationHook,
@@ -59,6 +60,7 @@ export const RESOLVERS: Record<string, ResolverFn> = {
REDACT_INVOCATION_BLOCK: generateRedactInvocationBlock,
THIRD_PARTY_ACTIONS: generateThirdPartyActions,
DESIGN_DOC_DISCOVERY: generateDesignDocDiscovery,
SHARED_LIBS_RUBRIC: generateSharedLibsRubric,
UNTRUSTED_CONTENT_WARNING: generateUntrustedContentWarning,
COMMAND_REFERENCE: generateCommandReference,
SNAPSHOT_FLAGS: generateSnapshotFlags,
@@ -70,13 +70,13 @@ Completeness: use \`Completeness: N/10\` only when options differ in coverage. 1
Accepted shortcuts leave a trail: when the user selects an option that is BOTH Completeness ≤ 7 AND a durable-scope call (architecture or scope-cut — never a turn-level choice), log it via \`gstack-decision-log\` with the ceiling and the upgrade trigger in the rationale, and — as part of implementing that option, same edit, no follow-up question — mark each cut corner in code with \`gstack-shortcut(dec-<id>): <ceiling>, upgrade when <trigger>\` in the language's comment syntax. Never agent-initiated: the marker exists only downstream of the user's explicit choice. /retro harvests these into a debt ledger, joined on the decision id.
Pros / cons: use ✅ and ❌. Minimum 2 pros and 1 con per option when the choice is real; Minimum 40 characters per bullet. Hard-stop escape for one-way/destructive confirmations: \`✅ No cons — this is a hard-stop choice\`.
\`Pros / cons:\` in question text; descriptions use literal ✅/❌ bullets, not Pro:/Con:. Each real option: ≥2 pros and ≥1 con, ≥40 chars each. One-way/destructive escape: \`✅ No cons — this is a hard-stop choice\`.
Neutral posture: \`Recommendation: <default> — this is a taste call, no strong preference either way\`; \`(recommended)\` STAYS on the default option for AUTO_DECIDE.
Effort both-scales: when an option involves effort, label both human-team and CC+gstack time, e.g. \`(human: ~2 days / CC: ~15 min)\`. Makes AI compression visible at decision time.
Net line closes the tradeoff. Per-skill instructions may add stricter rules.
\`Net:\` line closes question text. Per-skill instructions may add stricter rules.
### Handling 5+ options — split, never drop
@@ -114,10 +114,10 @@ ${planReview ? `Before emitting a tool or prose decision brief, verify:
- [ ] ELI10 paragraph present (stakes line too)
- [ ] Recommendation line present with concrete reason
- [ ] Completeness scored (coverage) OR kind-note present (kind)
- [ ] Every option has ≥2 ✅ and ≥1 ❌, each ≥40 chars (or hard-stop escape)
- [ ] \`Pros / cons:\` in question; options: ≥2 ✅, ≥1 ❌, ≥40 chars/bullet (or escape)
- [ ] (recommended) label on one option (even for neutral-posture)
- [ ] Dual-scale effort labels on effort-bearing options (human / CC)
- [ ] Net line closes the decision
- [ ] \`Net:\` closes question text
- [ ] You are calling the tool, not writing prose — unless \`CONDUCTOR_SESSION: true\` (then prose is the DEFAULT, not the tool) OR the documented failure fallback applies (then: the prose fallback's mandatory triad + a "reply with a letter" instruction, then STOP); in \`SESSION_KIND: spawned\` (the echoed STATUS line only) you should never reach this checklist — auto-choose the recommended option, no tool call, no prose
- [ ] Non-ASCII characters (CJK / accents) written directly, NOT \\u-escaped
- [ ] If you had 5+ options, you split (or batched into ≤4-groups) — did NOT drop any
+23 -11
View File
@@ -16,7 +16,7 @@ function generateSpecialistSelection(ctx: TemplateContext): string {
const isShip = ctx.skillName === 'ship';
const stepSel = isShip ? '9.1' : '4.5';
const stepMerge = isShip ? '9.2' : '4.6';
const nextStep = isShip ? 'the Fix-First flow (item 4)' : 'Step 5';
const nextStep = isShip ? 'Step 9.3 (cross-review dedup)' : 'Step 5';
return `## Step ${stepSel}: Review Army — Specialist Dispatch
### Detect stack and scope
@@ -60,7 +60,7 @@ Based on the scope signals above, select which specialists to dispatch.
1. **Testing** — read \`${ctx.paths.skillRoot}/review/specialists/testing.md\`
2. **Maintainability** — read \`${ctx.paths.skillRoot}/review/specialists/maintainability.md\`
**If DIFF_LINES < 50:** Skip all specialists. Print: "Small diff ($DIFF_LINES lines) — specialists skipped." Continue to ${nextStep}.
**If DIFF_LINES < 50:** Skip all specialists. Print: "Small diff ($DIFF_LINES lines) — specialists skipped." Continue to ${nextStep}. This threshold only gates specialist dispatch; any core shared-code check still runs.
**Conditional (dispatch if the matching scope signal is true):**
3. **Security** — if SCOPE_AUTH=true, OR if SCOPE_BACKEND=true AND DIFF_LINES > 100. Read \`${ctx.paths.skillRoot}/review/specialists/security.md\`
@@ -114,7 +114,9 @@ For each finding, output a JSON object on its own line:
{\\"severity\\":\\"CRITICAL|INFORMATIONAL\\",\\"confidence\\":N,\\"path\\":\\"file\\",\\"line\\":N,\\"category\\":\\"category\\",\\"summary\\":\\"description\\",\\"fix\\":\\"recommended fix\\",\\"fingerprint\\":\\"path:line:category\\",\\"specialist\\":\\"name\\"}
Required fields: severity, confidence, path, category, summary, specialist.
Optional: line, fix, fingerprint, evidence, test_stub.
Optional: line, fix, fingerprint, evidence, test_stub, advisory, evidence_paths, helper_target.
Optional extraction advice belongs to the core shared-code check; do not duplicate its proposals. Report real defects in duplicated code independently. Preserve advisory metadata when returning structural advice, and never label a demonstrated defect advisory merely because sharing a helper could fix it.
If you can write a test that would catch this issue, include it in the \`test_stub\` field.
Use the detected test framework ({TEST_FW}). Write a minimal skeleton — describe/it/test
@@ -139,7 +141,7 @@ function generateFindingsMerge(ctx: TemplateContext): string {
const isShip = ctx.skillName === 'ship';
const stepMerge = isShip ? '9.2' : '4.6';
const stepSel = isShip ? '9.1' : '4.5';
const fixFirstRef = isShip ? 'the Fix-First flow (item 4)' : 'Step 5 Fix-First';
const fixFirstRef = isShip ? 'Step 9.3 dedup, then Step 9.4 Fix-First' : 'Step 5 Fix-First';
const critPassRef = isShip ? 'the checklist pass (Step 9)' : 'the CRITICAL pass findings from Step 4';
const persistRef = isShip ? 'the review-log persist' : 'the review-log entry in Step 5.8';
return `### Step ${stepMerge}: Collect and merge findings
@@ -152,12 +154,17 @@ For each specialist's output:
2. Otherwise, parse each line as a JSON object. Skip lines that are not valid JSON.
3. Collect all parsed findings into a single list, tagged with their specialist name.
**Validate advisory severity first.** If a current finding has \`"severity":"CRITICAL"\` and \`"advisory":true\`, remove \`advisory\` and retain its \`CRITICAL\` severity. Handle it as a normal defect before fingerprinting, partitioning, deduplication, counting, scoring, and Fix-First. Never downgrade severity to make advisory metadata consistent. Valid INFORMATIONAL advisories remain advisory in every category, including simplification. Apply this validation to core and specialist findings alike before combining them.
**Fingerprint and deduplicate:**
For each finding, compute its fingerprint:
- For a shared-code advisory (category \`shared-libs\` or a \`shared-libs:\` fingerprint), call the installed \`sharedLibsFingerprint\` helper from \`${ctx.paths.skillRoot}/lib/review-evidence.ts\` with literal JSON on stdin, as in the core pass. Recompute from \`evidence_paths\` and \`helper_target\`; never trust a supplied hash or generate hash text yourself. Missing/malformed metadata cannot deduplicate or reuse a saved decision.
- If \`fingerprint\` field is present, use it
- Otherwise: \`{path}:{line}:{category}\` (if line is present) or \`{path}:{category}\`
Group findings by fingerprint. For findings sharing the same fingerprint:
The last two rules apply only to other findings. Preserve \`advisory\`, \`evidence_paths\`, and \`helper_target\` through merging. Core review owns shared-code proposals: consolidate equivalent specialist advice with the core proposal and count overlapping savings once. Keep the actual specialist activity in its stats; core-only advice must not create a specialist dispatch or finding.
Partition defects and advisories BEFORE grouping by fingerprint. A defect and an advisory must never merge with each other, even if a supplied fingerprint collides. A higher-confidence advisory or prior skipped extraction cannot replace, downgrade, or suppress a demonstrated defect. For findings sharing the same fingerprint within the same partition:
- Keep the finding with the highest confidence score
- Tag it: "MULTI-SPECIALIST CONFIRMED ({specialist1} + {specialist2})"
- Boost confidence by +1 (cap at 10)
@@ -169,11 +176,13 @@ Group findings by fingerprint. For findings sharing the same fingerprint:
- Confidence 3-4: move to appendix (suppress from main findings)
- Confidence 1-2: suppress entirely
**Advisory carve-out (simplification specialist):**
Findings with \`"advisory": true\` are excluded from BOTH the quality_score
**Advisory carve-out (all sources, including core shared-code and simplification):**
After severity validation, remaining findings with \`"advisory": true\` are excluded from BOTH the quality_score
summation and the findings-count header below — they are structure suggestions,
not defects, and must not make "5 findings … 10/10" look contradictory. In
Fix-First they are ASK-only: NEVER auto-applied, even when mechanical.
Fix-First they are ASK-only: NEVER auto-applied, even when mechanical. Also exclude
them from unresolved-defect totals and clean-status blockers. Preserve normal
Fix-First handling for any real defect affecting the same code.
**Compute PR Quality Score:**
After merging, compute the quality score over NON-advisory findings only:
@@ -203,6 +212,8 @@ PR Quality Score: X/10
\`Simplification: lean already — nothing to cut.\`
- If it was not dispatched, print neither line.
Do not add core shared-code savings to this specialist footer. Explain any overlap once in the core proposal instead of presenting duplicate savings.
These findings flow into ${fixFirstRef} alongside ${critPassRef}.
The Fix-First heuristic applies identically — specialist findings follow the same AUTO-FIX vs ASK classification (except advisory findings, which are ASK-only per the carve-out above).
@@ -215,7 +226,8 @@ For each specialist (testing, maintainability, security, performance, data-migra
- If not applicable (e.g., red-team not activated): omit from the object
Advisory findings COUNT in the stats \`findings\` field — the advisory
carve-out governs the quality score and the findings-count header only.
carve-out governs defect counts, score penalties, and clean-status blockers,
not specialist activity. Count only findings that specialist actually returned.
Logging simplification's advisories as \`findings: 0\` would auto-gate the
lens into permanent silence after 10 dispatches.
@@ -226,7 +238,7 @@ Remember these stats — you will need them for ${persistRef}.`;
function generateRedTeam(ctx: TemplateContext): string {
const isShip = ctx.skillName === 'ship';
const stepMerge = isShip ? '9.2' : '4.6';
const fixFirstRef = isShip ? 'the Fix-First flow (item 4)' : 'Step 5 Fix-First';
const fixFirstRef = isShip ? 'Step 9.3 dedup, then Step 9.4 Fix-First' : 'Step 5 Fix-First';
return `### Red Team dispatch (conditional)
**Activation:** Only if DIFF_LINES > 200 OR any specialist produced a CRITICAL finding.
@@ -249,7 +261,7 @@ If the Red Team finds additional issues, merge them into the findings list befor
${fixFirstRef}. Red Team findings are tagged with \`"specialist":"red-team"\`.
If the Red Team returns NO FINDINGS, note: "Red Team review: no additional issues found."
If the Red Team subagent fails or times out, skip silently and continue.`;
${isShip ? 'If the Red Team subagent fails or times out, continue through dedup and persistence with dispatched coverage incomplete. Step 9.4 must not certify that pass as completed or clean.' : 'If the Red Team subagent fails or times out, skip silently and continue.'}`;
}
export function generateReviewArmy(ctx: TemplateContext): string {
+95 -12
View File
@@ -75,6 +75,8 @@ ${['plan-ceo-review', 'plan-eng-review'].includes(ctx.skillName) ? 'Display a fr
- Plan-tier rows (plan-ceo-review, plan-eng-review, plan-design-review, codex-plan-review) grade a plan file, not the repo tree — never apply the wtree rule to them; they keep the 7-day freshness logic. If an entry carries \`plan_sha256\`, you MAY compare it with the plan file and note "plan changed since review" on mismatch.
- Plan-tier fallback only: parse \`---HEAD---\`. For entries with a different \`commit\`, count elapsed commits: \`git rev-list --count STORED_COMMIT..HEAD\`. If that command FAILS, grade UNKNOWN and treat as stale. Display: "Note: {skill} review from {date} may be stale — {N} commits since review". Missing commit tracking retains the legacy note to consider re-running.
- If all reviews grade CURRENT, do not display staleness notes`;
if (ctx.skillName === 'ship') return result.replace(/^- \*\*Eng Review \(required by default\):\*\*.*$/m,
'- **Eng Review (historical readiness):** Required for a CLEARED dashboard, not for continuing Step 1. Step 9 remains mandatory, with its finding, approval and convergence gates. The skip_eng_review setting changes this dashboard only.');
return ctx.skillName === 'plan-eng-review' ? result.replaceAll('\\`', '`') : result;
}
@@ -1375,7 +1377,7 @@ Continue to Step 9 to commit and publish the approved documentation edits.
// ─── Plan File Discovery (shared helper) ──────────────────────────────
function generatePlanFileDiscovery(): string {
function generatePlanFileDiscovery(ship = false): string {
return `### Plan File Discovery
1. **Conversation context (primary):** Check if there is an active plan file in this conversation. The host agent's system messages include plan file paths when in plan mode. If found, use it directly — this is the most reliable signal.
@@ -1404,7 +1406,7 @@ done
**Error handling:**
- No plan file found → skip with "No plan file detected — skipping."
- Plan file found but unreadable (permissions, encoding) → skip with "Plan file found but unreadable — skipping."`;
${ship ? '- Plan file found but unreadable (permissions, encoding) → return an audit error to the parent. Do not report no plan or successful zero counts; the parent applies its audit-failure recovery and skip/stop decision.' : '- Plan file found but unreadable (permissions, encoding) → skip with "Plan file found but unreadable — skipping."'}`;
}
// ─── Plan Completion Audit ────────────────────────────────────────────
@@ -1416,7 +1418,7 @@ function generatePlanCompletionAuditInner(mode: PlanCompletionMode, part: 'audit
let gate = '';
// ── Plan file discovery (shared) ──
sections.push(generatePlanFileDiscovery());
sections.push(generatePlanFileDiscovery(mode === 'ship'));
// ── Item extraction ──
sections.push(`
@@ -1452,7 +1454,7 @@ For each item, note:
Before judging completion, classify HOW each item can be verified. The diff alone cannot prove every kind of work. Items outside the current repo or system are structurally invisible to \`git diff\`.
- **DIFF-VERIFIABLE** — A code change in this repo would manifest in \`git diff <base>...HEAD\`. Examples: "add UserService" (file appears), "validate input X" (validation logic appears), "create users table" (migration file appears).
- **DIFF-VERIFIABLE** — A code change in this repo would manifest in \`git diff ${mode === 'ship' ? 'origin/<base>' : '<base>...HEAD'}\`. Examples: "add UserService" (file appears), "validate input X" (validation logic appears), "create users table" (migration file appears).
- **CROSS-REPO** — Item names a file or change in a sibling repo (e.g., \`domain-hq/docs/dashboard.md\`, \`~/Development/<other-repo>/...\`). The current diff CANNOT prove this.
- **EXTERNAL-STATE** — Item names state in an external system: Supabase config/RLS, Cloudflare DNS, Vercel env vars, OAuth provider allowlists, third-party SaaS, DNS records. The current diff CANNOT prove this.
- **CONTENT-SHAPE** — Item requires a file to follow a specific convention. If the file is in this repo: diff-verifiable. If in another repo or system: see CROSS-REPO / EXTERNAL-STATE.
@@ -1474,7 +1476,7 @@ Before judging completion, classify HOW each item can be verified. The diff alon
sections.push(`
### Cross-Reference Against Diff
Run \`git diff origin/<base>...HEAD\` and \`git log origin/<base>..HEAD --oneline\` to understand what was implemented.
Run \`git diff origin/<base>${mode === 'ship' ? '' : '...HEAD'}\` and \`git log origin/<base>..HEAD --oneline\` to understand what was implemented.
For each extracted plan item, run the verification dispatch from the previous section, then classify:
@@ -1714,14 +1716,20 @@ Follow the /qa-only workflow with these modifications:
### 4. Gate logic
- **All verification items PASS:** Continue silently. "Plan verification: PASS."
- **Any FAIL:** Use AskUserQuestion:
Record the actual result even when the user accepts a failure.
- **All verification items PASS:** Set VERIFY_RESULT=pass. Continue silently. "Plan verification: PASS."
- **Any FAIL:** Set VERIFY_RESULT=fail, then use AskUserQuestion:
- Show the failures with screenshot evidence
- RECOMMENDATION: Choose A if failures indicate broken functionality. Choose B if cosmetic only.
- Options:
A) Fix the failures before shipping (recommended for functional issues)
B) Ship anyway — known issues (acceptable for cosmetic issues)
- **No verification section / no server / unreadable skill:** Skip (non-blocking).
- **No verification section / no server / unreadable skill:** Set VERIFY_RESULT=skipped; record the reason (non-blocking).
Fix before shipping returns to implementation, then reruns affected tests and this
verification. Ship anyway retains VERIFY_RESULT=fail and lists the accepted
failures in the PR; approval never turns failed verification into a pass.
### 5. Include in PR body
@@ -1741,7 +1749,11 @@ export function generateCrossReviewDedup(ctx: TemplateContext): string {
return `### Step ${stepNum}: Cross-review finding dedup
Before classifying findings, check if any were previously skipped by the user in a prior review on this branch.
**Validate advisory severity first.** If a current finding has \`"severity":"CRITICAL"\` and \`"advisory":true\`, remove \`advisory\` and retain its \`CRITICAL\` severity. Handle it as a normal defect before suppression, classification, counting, scoring, and persistence. Never downgrade severity to make advisory metadata consistent. Valid INFORMATIONAL advisories remain advisory in every category, including simplification. A prior saved finding with contradictory CRITICAL/advisory metadata cannot establish a skipped defect or advisory decision: exclude it from reuse and revalidate the current finding.
Before classifying findings, check if any were previously skipped by the user in a prior review on this branch.${isShip ? `
**Execution:** Read prior records once. If there are no explicitly skipped findings, continue to Step 9.4. For ordinary findings use the primary-file rule below. Run the shared-code procedure only for a matching skipped advisory. Stop its eligibility checks at the first missing or unverifiable condition and re-review the supporting source for a fresh decision; incomplete evidence never permits suppression.` : ''}
\`\`\`bash
~/.claude/skills/gstack/bin/gstack-review-read
@@ -1749,7 +1761,12 @@ Before classifying findings, check if any were previously skipped by the user in
Parse the output: only lines BEFORE \`---CONFIG---\` are JSONL entries (the output also contains \`---CONFIG---\` and \`---HEAD---\` footer sections that are not JSONL — ignore those).
For each JSONL entry that has a \`findings\` array:
**Shared-code advisory decisions use the stricter rule below.** Do not send a
finding through the ordinary primary-file rule if its category is \`shared-libs\`,
its fingerprint starts \`shared-libs:\`, or it has \`evidence_paths\` / \`helper_target\`.
Missing legacy metadata requires revalidation, not fallback to a line fingerprint.
For each JSONL entry that has a \`findings\` array, for ordinary findings only:
1. Collect all fingerprints where \`action: "skipped"\`
2. Note the \`commit\` field from that entry
@@ -1762,8 +1779,69 @@ git diff --name-only <prior-review-commit> HEAD
For each current finding (from both ${findingsRef}), check:
- Does its fingerprint match a previously skipped finding?
- Is the finding's file path NOT in the changed-files set?
- Is it the same advisory/defect kind? Never use a skipped advisory to suppress a real defect, including a defect with a colliding supplied fingerprint.
If both conditions are true: suppress the finding. It was intentionally skipped and the relevant code hasn't changed.
If all conditions are true: suppress the finding. It was intentionally skipped and the relevant code hasn't changed.
**Reuse a skipped shared-code advisory only with complete structural evidence:**
1. Recompute both structural identities with \`sharedLibsFingerprint\` from
\`${ctx.paths.skillRoot}/lib/review-evidence.ts\` before deduplication. Both must
be valid, both findings must explicitly be advisory, the prior saved hash must
match its recomputation, and the prior action must explicitly be \`skipped\`.
Retain \`evidence_paths\` and \`helper_target\`; line numbers and a primary path
alone cannot identify an extraction.
2. Require a prior completed, converged \`review\` with verified binding and
start/end/record fingerprints equal to current \`---WTREE---\`. Read REVIEW_START
without consuming it; its repo, raw branch and fingerprint must match the current
repo, branch and snapshot. Missing, changed or unknown fields/token require
revalidation. Do not mint a new token to enable suppression.
3. Match prior trusted \`review_binding.branch_id\` to SHA-256 of the exact
current raw branch, matching the capture. Compute the digest in code, never
as model-generated text. Sanitized log filenames are not branch identity:
\`topic/a\` and \`topic-a\` can collide.
4. Verify EVERY evidence path against the snapshot. Enumerate tracked/non-ignored
untracked paths, then raw-read/lstat each file and path component; \`ls-files\`
alone is insufficient. Revalidate symlink targets/ancestors, submodules,
ignored/outside files and missing/unreadable paths: the parent fingerprint
does not cover them. Inspect effective Git attributes/config without conversion:
filter, working-tree-encoding, ident, text/eol and core.autocrlf can hide raw
changes. Active/unknown transformations require fresh raw-source review even
with an unchanged filtered tree. Disable fsmonitor and optional locks.
Exclude assume-unchanged, skip-worktree and sparse index entries. Compare each
raw file byte-for-byte with its blob in that exact working-tree snapshot,
using Git object reads without external diff/textconv or normalization.
Missing blobs, mismatches or unknown coverage require revalidation.
Only verified regular, untransformed,
in-repository paths enter \`covered_paths\`.
The prior finding's \`snapshot_covered_paths\` must also cover every evidence
path; current eligibility cannot prove what prior filters/index flags hid.
Missing prior coverage is legacy metadata; revalidate it.
5. Call pure \`canReuseSharedLibsAdvisory\` with actually read records and verified
snapshot fields as literal JSON on stdin. The command below computes the live branch digest;
replace the empty example objects and keep the quoted delimiter:
\`\`\`bash
bun -e '
const { createHash } = await import("node:crypto");
const { canReuseSharedLibsAdvisory } = await import(process.argv[1]);
const input = JSON.parse(await Bun.stdin.text());
let branch = Bun.spawnSync(["git", "symbolic-ref", "--quiet", "--short", "HEAD"]);
if (branch.exitCode !== 0) branch = Bun.spawnSync(["git", "rev-parse", "HEAD"]);
if (branch.exitCode !== 0) { console.log(false); process.exit(0); }
const rawBranch = branch.stdout.toString().replace(/\\r?\\n$/, "");
const snapshot = { ...input.currentSnapshot, branch_id: createHash("sha256").update(rawBranch, "utf8").digest("hex") };
console.log(canReuseSharedLibsAdvisory(input.priorFinding, input.currentFinding, input.priorReview, snapshot));
' "${toShellPath(ctx.paths.skillRoot)}/lib/review-evidence.ts" <<'GSTACK_SHARED_LIBS_REUSE_JSON'
{"priorFinding":{},"currentFinding":{},"priorReview":{},"currentSnapshot":{"wtree":"","covered_paths":[]}}
GSTACK_SHARED_LIBS_REUSE_JSON
\`\`\`
Suppress only when ALL eligibility checks passed and the helper returns true.
Otherwise re-read all supporting callers and present any still-supported advice
for a fresh decision. A changed secondary caller or changed raw bytes matter even
when the primary anchor, commit, or normalized Git tree appears unchanged. A real
defect always retains normal Fix-First handling independently of this advice.
Print: "Suppressed N findings from prior reviews (previously skipped by user)"
@@ -1771,5 +1849,10 @@ Print: "Suppressed N findings from prior reviews (previously skipped by user)"
If no prior reviews exist or none have a \`findings\` array, skip this step silently.
Output a summary header: \`Pre-Landing Review: N issues (X critical, Y informational)\``;
Output a summary header: \`Pre-Landing Review: N issues (X critical, Y informational)\`.
Count only non-advisory defects in that header; list optional advice separately
with \`[ADVISORY]\`. Preserve advisory records and explicit decisions for
persistence, but exclude advisories from score penalties, unresolved-defect
totals, and clean-status blockers. This does not relax completion, convergence,
or missing-reviewer rules.`;
}
+31
View File
@@ -0,0 +1,31 @@
import type { ResolverFn } from './types';
/** Shared criteria only: the caller owns scope, output, and permission to act. */
export const generateSharedLibsRubric: ResolverFn = () => `### Shared-code evaluation rubric
- **Prove the callers.** Require at least two verified, first-party authored source
locations, with functions and lines. Actual added or uncommitted source qualifies.
Only an engineering-plan review may use proposed callers; label those assumptions
and distinguish them from existing source. Similar names or formatting alone do
not establish equivalent behavior. Generated and third-party copies cannot qualify
as callers or contribute savings. Follow generated copies back to authored
templates/resolvers. Existing dependencies remain valid reuse targets.
- **Reuse before extracting.** Inspect existing libraries and helpers first. Compare
behavior, inputs, outputs, error handling, side effects, security requirements,
dependencies, and deployment/runtime boundaries. Preserve differences callers need;
do not bridge languages or isolated deployments without a practical shared contract.
- **Keep the helper small.** Name its destination and contract, the callers to migrate,
and the smallest adoption sequence. Avoid option-heavy helpers and coupling unrelated
components. Point to existing tests or established use, specify shared-contract and
caller-integration coverage, and describe the blast radius of a shared failure.
- **Account for the whole change.** Name removed blocks and their replacements. Show
estimated implementation lines removed, added, and saved separately from total lines
removed, added, and saved including tests and integration. Savings = removed - added.
Count moved code on both sides, exclude generated/vendor lines, use ranges when
uncertain, and do not count overlapping removals twice across opportunities. State
when tests or integration may make the total change grow.
- **Rank useful changes.** Favor reliability gains and total net savings, then low
adoption and testing risk. Prefer proven code used by several callers. Use recent
activity to break ties between comparable benefits, not as evidence by itself.
Explain choices centered on older code. Reject similarities with incompatible
contracts and opportunities whose benefits do not justify the abstraction.`;
+3 -3
View File
@@ -275,7 +275,7 @@ Store this number for the PR body.`);
? `**Step 1. Trace every codepath in the plan:**
Read the plan document. For each new feature, service, endpoint, or component described, trace how data will flow through the code — don't just list planned functions, actually follow the planned execution:`
: `**${mode === 'ship' ? '1' : 'Step 1'}. Trace every codepath changed** using \`git diff origin/<base>...HEAD\`:
: `**${mode === 'ship' ? '1' : 'Step 1'}. Trace every codepath changed** using \`git diff origin/<base>${mode === 'ship' ? '' : '...HEAD'}\`:
Read every changed file. For each one, trace how data flows through the code — don't just list functions, actually follow the execution:`;
@@ -301,8 +301,8 @@ branch diff. A **prototype** is existing runnable code referenced by the plan,
not a proposed future component.
When grounded in concrete source and test files, read them in a dedicated tool
call before drawing the diagram. For targeted audits only, do this after Scope
Challenge resolves and before Step 2. Map user flows. Do not mix diff, grep,
call before drawing the diagram. Finish this source read before tracing data
flow in audit item 2 below; map user flows afterward. Do not mix diff, grep,
package/config, git, or commentary into that read; use separate calls for
context. Base the diagram on that read.
`}2. **Trace data flow.** Starting from each entry point (route handler, exported function, event listener, component render), follow the data through every branch:
+4 -4
View File
@@ -462,20 +462,20 @@ export function generateSetupCommand(ctx: TemplateContext): string {
return ctx.host === 'claude' ? './setup' : `./setup --host ${ctx.host}`;
}
export function generateChangelogWorkflow(_ctx: TemplateContext): string {
export function generateChangelogWorkflow(ctx: TemplateContext): string {
return `## Step 13: CHANGELOG (auto-generate)
1. Read \`CHANGELOG.md\` header to know the format.
2. **First, enumerate every commit on the branch:**
\`\`\`bash
git log <base>..HEAD --oneline
git log ${ctx.skillName === 'ship' ? 'origin/<base>' : '<base>'}..HEAD --oneline
\`\`\`
Copy the full list. Count the commits. You will use this as a checklist.
3. **Read the full diff** to understand what each commit actually changed:
\`\`\`bash
git diff <base>...HEAD
git diff ${ctx.skillName === 'ship' ? 'origin/<base>' : '<base>...HEAD'}
\`\`\`
4. **Group commits by theme** before writing anything. Common themes:
@@ -494,7 +494,7 @@ export function generateChangelogWorkflow(_ctx: TemplateContext): string {
- \`### Fixed\` — bug fixes
- \`### Removed\` — removed features
- Write concise, descriptive bullet points
- Insert after the file header (line 5), dated today
- ${ctx.skillName === 'ship' ? 'Insert after the observed file header, before the first release entry, dated today' : 'Insert after the file header (line 5), dated today'}
- Format: \`## [X.Y.Z.W] - YYYY-MM-DD\`
- **Voice:** Lead with what the user can now **do** that they couldn't before. Use plain language, not implementation details. Never mention TODOS.md, internal tracking, or contributor-facing details.