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>

plan-eng-review/SKILL.md

@@ -69,8 +69,9 @@ After target selection, every question uses the preamble's full decision brief,
 **Startup sequence** (after target selection):
 1. Run the Preamble, including Context Recovery and its setup questions.
 2. Load available Brain Context before Step 0/review questions; do not repeat setup.
-3. Complete web-research readiness, Design Doc Check and the prerequisite offer.
-4. Continue at **Engineering review → Step 0** below; its section Read loads Review preparation and Scope Challenge together.
+3. Check web-research readiness at **Web research runs in Aside**.
+4. Run **Design Doc Check**, then **Prerequisite Skill Offer**.
+5. Continue at **Engineering review → Step 0** below; its section Read loads Review preparation and Scope Challenge together.
 
 Keep the reviewed target fixed when selecting the section's separate report destination.
 
@@ -182,13 +183,13 @@ Completeness: use `Completeness: N/10` only when options differ in coverage. 10
 
 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
 
@@ -475,40 +476,39 @@ Skills that run plan reviews (`/plan-*-review`, `/codex review`) include the EXI
 
 
 ## Priority hierarchy
-If the user asks you to compress or the system triggers context compaction: Step 0 > Test diagram > Opinionated recommendations > Everything else. Never skip Step 0 or the test diagram. Do not preemptively warn about context limits -- the system handles compaction automatically.
+On compression: Step 0 > Test diagram > Opinionated recommendations > Everything else. Never skip Step 0 or the test diagram. The system handles context limits; do not preemptively warn.
 
 ## My engineering preferences (use these to guide your recommendations):
-* **DRY:** flag repetition aggressively.
-* **Tests:** well-tested code is non-negotiable; prefer too many tests to too few.
-* **Enough engineering:** avoid both fragile hacks and premature abstraction or complexity.
-* **Edge cases:** favor thorough handling and thoughtfulness over speed.
+* **Shared code:** require common behavior and improved reliability or net savings; similar-looking code alone is insufficient.
+* **Tests:** non-negotiable; prefer too many to too few.
+* **Enough engineering:** avoid fragility and premature abstraction/complexity.
+* **Edge cases:** thorough handling over speed.
 * **Explicit over clever.**
-* **Right-sized diff:** choose the smallest clear change. If the foundation is broken, recommend a rewrite rather than preserving it for a smaller diff.
+* **Right-sized diff:** smallest clear change; rewrite a broken foundation when necessary.
 
 ## Cognitive Patterns — How Great Eng Managers Think
 
-Apply these instincts throughout; they are not extra checklist items.
+Apply throughout, not as extra checks:
 
-1. **State diagnosis:** Match the intervention to falling behind, treading water, repaying debt or innovating (Larson).
-2. **Blast radius:** Trace worst-case effects on systems and people.
-3. **Boring by default:** Budget about three innovation tokens; otherwise use proven technology (McKinley).
-4. **Incremental change:** Prefer strangler migrations and canaries to big-bang rewrites and rollouts (Fowler).
+1. **State diagnosis:** Match falling behind, treading water, repaying debt or innovating (Larson).
+2. **Blast radius:** Trace worst-case harm to systems and people.
+3. **Boring by default:** Three innovation tokens; otherwise proven technology (McKinley).
+4. **Incremental change:** Strangler migrations and canaries over big bangs (Fowler).
 5. **Systems over heroes:** Design for tired humans at 3am.
-6. **Reversibility:** Use flags and incremental rollout; make wrong choices cheap to undo.
-7. **Failure is information:** Learn through blameless postmortems, error budgets and chaos engineering (Allspaw, Google SRE).
-8. **Conway's Law:** Design team and system boundaries together (Skelton/Pais).
-9. **DX signals quality:** Slow CI, local dev and deploys hurt software and retention; treat them as leading indicators.
-10. **Essential vs accidental complexity:** Are we solving a real problem or one we created? (Brooks).
-11. **Two-week smell:** Difficulty shipping a small feature in two weeks points to onboarding problems.
-12. **Glue work:** Recognize invisible coordination without trapping people in it (Reilly).
-13. **Make change easy first:** Refactor before changing behavior; separate structural and behavioral changes (Beck).
-14. **Own production:** Development and operations share responsibility (Majors).
-15. **Error budgets:** An SLO of 99.9% permits 0.1% downtime; allocate that budget instead of maximizing uptime at any cost (Google SRE).
+6. **Reversibility:** Flags and incremental rollouts make mistakes cheap to undo.
+7. **Failure is information:** Blameless postmortems, error budgets, chaos engineering (Allspaw, Google SRE).
+8. **Conway's Law:** Design team/system boundaries together (Skelton/Pais).
+9. **DX signals quality:** Slow CI, local dev and deploys predict quality and retention trouble.
+10. **Essential vs accidental complexity:** Real problem or self-created? (Brooks).
+11. **Two-week smell:** A small feature taking two weeks suggests onboarding trouble.
+12. **Glue work:** Value coordination without trapping people in it (Reilly).
+13. **Make change easy first:** Refactor before behavior changes; keep them separate (Beck).
+14. **Own production:** Dev and ops share responsibility (Majors).
+15. **Error budgets:** Spend a 99.9% SLO's 0.1% downtime budget; avoid uptime at any cost (Google SRE).
 
 ## Documentation and diagrams:
-* Use ASCII diagrams liberally for data flow, state machines, dependencies, pipelines and decision trees in plans and design docs.
-* Add inline ASCII diagrams in code comments for complex behavior: Models (data/state), Controllers (request flow), Concerns (mixin behavior), Services (pipelines), and Tests (non-obvious setup or purpose).
-* **Maintain diagrams with code.** Check nearby diagrams when changing code and update them in the same commit. Stale diagrams mislead; flag those found even outside the immediate change's scope.
+* Use ASCII diagrams for flows, states, dependencies, pipelines and decisions in plans/docs; propose inline code diagrams for complex Models, Controllers, Concerns, Services and Tests.
+* Update nearby diagrams with code in the same commit. Flag stale diagrams even outside scope.
 
 ## Brain Context (preflight)
 
@@ -609,7 +609,8 @@ else
 fi
 ```
 If the slug helper fails, treat design context as unavailable and continue to the prerequisite offer; do not infer a design doc path.
-If a design doc exists, read it. Use it as the source of truth for the problem statement, constraints, and chosen approach. If it has a `Supersedes:` field, note that this is a revised design — check the prior version for context on what changed and why.
+Read any design doc as the source of truth for the problem, constraints and approach.
+`Supersedes:` marks a revision; check the prior version for what changed and why.
 
 ## Prerequisite Skill Offer
 
@@ -675,7 +676,10 @@ Scope Challenge is mandatory before Section 1.
 
 ## Section self-check (before you finish)
 
-Verify you Read `sections/review-sections.md` and fully executed Scope Challenge, Architecture, Code Quality, Tests, Performance, Outside Voice and required outputs. Redo work attempted from memory after Reading that section.
+Confirm you read the section and completed Scope Challenge, Sections 1–4,
+Outside Voice and outputs. If evidence is missing, Read `sections/review-sections.md`
+and repair only gaps through its decision/output recovery steps. Preserve
+verified work.
 
 **Paused question:** Wait for its actual answer without completion telemetry or ExitPlanMode.