ralph-prd 1.0.4 → 1.0.6

package/ralph/test/ship-checker.test.mjs

@@ -0,0 +1,268 @@
+import { test, describe } from 'node:test';
+import assert from 'node:assert/strict';
+import { join } from 'path';
+import { existsSync, mkdirSync, writeFileSync } from 'fs';
+import { runShipCheck, ShipCheckError } from '../lib/ship-checker.mjs';
+import { LogWriter } from '../lib/log-writer.mjs';
+import { makeTempDir, makeFakeSend } from './helpers.mjs';
+
+const PHASE = {
+  index: 0,
+  title: 'Phase 1: CLI Shell',
+  body: '### What to build\nBuild CLI.\n\n### Acceptance criteria\n\n- [ ] Dry-run works',
+  acceptanceCriteria: ['Dry-run works'],
+  hasVerification: true,
+};
+
+const REPO_STATE = '`git status --short`:\n(no changes)';
+
+const SKILL_BODY = 'Review the phase implementation and emit VERDICT: APPROVED or VERDICT: REMARKS.';
+
+/** Write a minimal SKILL.md (with frontmatter) to a temp base dir and return the base dir. */
+function makeSkillDir(body = SKILL_BODY) {
+  const base = makeTempDir();
+  const skillDir = join(base, '.claude', 'skills', 'ship-check');
+  mkdirSync(skillDir, { recursive: true });
+  writeFileSync(
+    join(skillDir, 'SKILL.md'),
+    `---\nname: ship-check\n---\n\n${body}`,
+    'utf8'
+  );
+  return base;
+}
+
+function makeSetup() {
+  const logsDir = makeTempDir();
+  const lw = new LogWriter(logsDir, 'dump');
+  const skillsBase = makeSkillDir();
+  return { logsDir, lw, skillsBase };
+}
+
+describe('runShipCheck', () => {
+
+  test('APPROVED on first check → returns nextTaskNum = startTaskNum + 1', async () => {
+    const { lw, skillsBase } = makeSetup();
+    const send = makeFakeSend(['All looks good.\n\nVERDICT: APPROVED']);
+
+    const { nextTaskNum } = await runShipCheck({
+      phase: PHASE, repoState: REPO_STATE,
+      logWriter: lw, phaseNum: 1, startTaskNum: 2, send,
+      _skillsBase: skillsBase,
+    });
+
+    assert.equal(nextTaskNum, 3); // startTaskNum=2, one session => 3
+  });
+
+  test('REMARKS → repair → APPROVED: 3 sessions, nextTaskNum = startTaskNum + 3', async () => {
+    const { lw, skillsBase } = makeSetup();
+    const send = makeFakeSend([
+      'VERDICT: REMARKS\nFINDINGS_START\n- Missing tests\nFINDINGS_END',
+      'Fixed the tests.',
+      'VERDICT: APPROVED',
+    ]);
+
+    const { nextTaskNum } = await runShipCheck({
+      phase: PHASE, repoState: REPO_STATE,
+      logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+      _skillsBase: skillsBase,
+    });
+
+    assert.equal(nextTaskNum, 4); // 1 + 3 sessions
+  });
+
+  test('REMARKS → repair → APPROVED: repair prompt includes findings', async () => {
+    const { lw, skillsBase } = makeSetup();
+    let repairPrompt = '';
+    let call = 0;
+    const send = async (prompt, { onChunk } = {}) => {
+      call++;
+      let resp;
+      if (call === 1) {
+        resp = 'VERDICT: REMARKS\nFINDINGS_START\n- Need more error handling\nFINDINGS_END';
+      } else if (call === 2) {
+        repairPrompt = prompt;
+        resp = 'Fixed.';
+      } else {
+        resp = 'VERDICT: APPROVED';
+      }
+      onChunk?.(resp);
+      return resp;
+    };
+
+    await runShipCheck({
+      phase: PHASE, repoState: REPO_STATE,
+      logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+      _skillsBase: skillsBase,
+    });
+
+    assert.ok(repairPrompt.includes('Need more error handling'), 'repair prompt should contain findings');
+  });
+
+  test('REMARKS → repair → REMARKS: throws ShipCheckError', async () => {
+    const { lw, skillsBase } = makeSetup();
+    const send = makeFakeSend([
+      'VERDICT: REMARKS\nFINDINGS_START\n- Still broken\nFINDINGS_END',
+      'Tried to fix.',
+      'VERDICT: REMARKS\nFINDINGS_START\n- Still broken after repair\nFINDINGS_END',
+    ]);
+
+    await assert.rejects(
+      () => runShipCheck({
+        phase: PHASE, repoState: REPO_STATE,
+        logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+        _skillsBase: skillsBase,
+      }),
+      (err) => {
+        assert.ok(err instanceof ShipCheckError);
+        assert.equal(err.phaseName, 'Phase 1: CLI Shell');
+        assert.ok(err.findings.length > 0);
+        return true;
+      }
+    );
+  });
+
+  test('REMARKS → repair → REMARKS: ShipCheckError is distinct from VerificationError', async () => {
+    const { lw, skillsBase } = makeSetup();
+    const send = makeFakeSend([
+      'VERDICT: REMARKS\nFINDINGS_START\n- Bad\nFINDINGS_END',
+      'Fix attempt.',
+      'VERDICT: REMARKS\nFINDINGS_START\n- Still bad\nFINDINGS_END',
+    ]);
+
+    await assert.rejects(
+      () => runShipCheck({
+        phase: PHASE, repoState: REPO_STATE,
+        logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+        _skillsBase: skillsBase,
+      }),
+      (err) => {
+        assert.equal(err.name, 'ShipCheckError');
+        assert.ok(!(err.constructor.name === 'VerificationError'));
+        return true;
+      }
+    );
+  });
+
+  test('double-REMARKS: exactly 3 sessions total', async () => {
+    const { lw, skillsBase } = makeSetup();
+    let calls = 0;
+    const send = async (prompt, { onChunk } = {}) => {
+      calls++;
+      const resp = calls === 2
+        ? 'Fixed.'
+        : 'VERDICT: REMARKS\nFINDINGS_START\n- Problem\nFINDINGS_END';
+      onChunk?.(resp);
+      return resp;
+    };
+
+    try {
+      await runShipCheck({
+        phase: PHASE, repoState: REPO_STATE,
+        logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+        _skillsBase: skillsBase,
+      });
+    } catch { /* expected */ }
+
+    assert.equal(calls, 3, 'exactly 3 sessions: ship-check + repair + re-check');
+  });
+
+  test('all sessions write individual step logs', async () => {
+    const { logsDir, lw, skillsBase } = makeSetup();
+    const send = makeFakeSend([
+      'VERDICT: REMARKS\nFINDINGS_START\n- X\nFINDINGS_END',
+      'Fixed.',
+      'VERDICT: APPROVED',
+    ]);
+
+    await runShipCheck({
+      phase: PHASE, repoState: REPO_STATE,
+      logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+      _skillsBase: skillsBase,
+    });
+
+    assert.ok(existsSync(join(logsDir, 'phase-1-ship-check.log')));
+    assert.ok(existsSync(join(logsDir, 'phase-1-ship-check-repair.log')));
+    assert.ok(existsSync(join(logsDir, 'phase-1-ship-check-re.log')));
+  });
+
+  test('logs preserved after double-REMARKS', async () => {
+    const { logsDir, lw, skillsBase } = makeSetup();
+    const send = makeFakeSend([
+      'VERDICT: REMARKS\nFINDINGS_START\n- Bad\nFINDINGS_END',
+      'Tried to fix.',
+      'VERDICT: REMARKS\nFINDINGS_START\n- Still bad\nFINDINGS_END',
+    ]);
+
+    try {
+      await runShipCheck({
+        phase: PHASE, repoState: REPO_STATE,
+        logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+        _skillsBase: skillsBase,
+      });
+    } catch { /* expected */ }
+
+    assert.ok(existsSync(join(logsDir, 'phase-1-ship-check.log')));
+    assert.ok(existsSync(join(logsDir, 'phase-1-ship-check-repair.log')));
+    assert.ok(existsSync(join(logsDir, 'phase-1-ship-check-re.log')));
+  });
+
+  test('SKILL.md frontmatter is stripped before sending as prompt', async () => {
+    const logsDir = makeTempDir();
+    const lw = new LogWriter(logsDir, 'dump');
+    const skillsBase = makeSkillDir('Actual skill instructions here.');
+    let capturedPrompt = '';
+    const send = async (prompt, { onChunk } = {}) => {
+      capturedPrompt = prompt;
+      const resp = 'VERDICT: APPROVED';
+      onChunk?.(resp);
+      return resp;
+    };
+
+    await runShipCheck({
+      phase: PHASE, repoState: REPO_STATE,
+      logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+      _skillsBase: skillsBase,
+    });
+
+    assert.ok(capturedPrompt.includes('Actual skill instructions here.'));
+    assert.ok(!capturedPrompt.includes('name: ship-check'), 'frontmatter should be stripped');
+  });
+
+  test('missing SKILL.md throws a clear configuration error', async () => {
+    const { lw } = makeSetup();
+    const emptyBase = makeTempDir(); // no SKILL.md here
+    const send = makeFakeSend(['VERDICT: APPROVED']);
+
+    await assert.rejects(
+      () => runShipCheck({
+        phase: PHASE, repoState: REPO_STATE,
+        logWriter: lw, phaseNum: 1, startTaskNum: 1, send,
+        _skillsBase: emptyBase,
+      }),
+      (err) => {
+        assert.ok(err.message.includes('ship-check'), 'error should mention ship-check');
+        assert.ok(err.message.includes('SKILL.md'), 'error should mention SKILL.md');
+        return true;
+      }
+    );
+  });
+
+  test('APPROVED on re-check: findings from first REMARKS are not propagated to error', async () => {
+    const { lw, skillsBase } = makeSetup();
+    const send = makeFakeSend([
+      'VERDICT: REMARKS\nFINDINGS_START\n- Minor issue\nFINDINGS_END',
+      'Fixed the minor issue.',
+      'VERDICT: APPROVED',
+    ]);
+
+    // Should resolve without throwing
+    const result = await runShipCheck({
+      phase: PHASE, repoState: REPO_STATE,
+      logWriter: lw, phaseNum: 1, startTaskNum: 5, send,
+      _skillsBase: skillsBase,
+    });
+
+    assert.equal(result.nextTaskNum, 8); // 5 + 3 sessions
+  });
+
+});

package/skills/grill-me/SKILL.md

@@ -1,10 +0,0 @@
----
-name: grill-me
-description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
----
-
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time.
-
-If a question can be answered by exploring the codebase, explore the codebase instead.

package/skills/grill-me/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Grill Me"
-  short_description: "Stress-test a plan one question at a time"
-  default_prompt: "Use $grill-me to interrogate this plan or design relentlessly, ask one question at a time, and provide your recommended answer for each question."

package/skills/prd-to-plan/SKILL.md

@@ -1,107 +0,0 @@
----
-name: prd-to-plan
-description: Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
----
-
-# PRD to Plan
-
-Break a PRD into a phased implementation plan using vertical slices (tracer bullets). Output is a Markdown file in `./docs/<feature-name>/plan.md`.
-
-## Process
-
-### 1. Confirm the PRD is in context
-
-The PRD should already be in the conversation. If it isn't, ask the user to paste it or point you to the file.
-
-### 2. Explore the codebase
-
-If you have not already explored the codebase, do so to understand the current architecture, existing patterns, and integration layers.
-
-### 3. Identify durable architectural decisions
-
-Before slicing, identify high-level decisions that are unlikely to change throughout implementation:
-
-- Route structures / URL patterns
-- Database schema shape
-- Key data models
-- Authentication / authorization approach
-- Third-party service boundaries
-
-These go in the plan header so every phase can reference them.
-
-### 4. Draft vertical slices
-
-Break the PRD into **tracer bullet** phases. Each phase is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
-
-<vertical-slice-rules>
-- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
-- A completed slice is demoable or verifiable on its own
-- Prefer many thin slices over few thick ones
-- Do NOT include specific file names, function names, or implementation details that are likely to change as later phases are built
-- DO include durable decisions: route paths, schema shapes, data model names
-</vertical-slice-rules>
-
-### 5. Quiz the user
-
-Present the proposed breakdown as a numbered list. For each phase show:
-
-- **Title**: short descriptive name
-- **User stories covered**: which user stories from the PRD this addresses
-
-Ask the user:
-
-- Does the granularity feel right? (too coarse / too fine)
-- Should any phases be merged or split further?
-
-Iterate until the user approves the breakdown.
-
-### 6. Write the plan file
-
-Create `./docs/<feature-name>/` if it doesn't exist. Write the plan as a Markdown file named after the feature (e.g. `./docs/meta-direct-whatsapp/plan.md`). Use the template below.
-
-<plan-template>
-# Plan: <Feature Name>
-
-> Source PRD: <brief identifier or link>
-
-## Architectural decisions
-
-Durable decisions that apply across all phases:
-
-- **Routes**: ...
-- **Schema**: ...
-- **Key models**: ...
-- (add/remove sections as appropriate)
-
----
-
-## Phase 1: <Title>
-
-**User stories**: <list from PRD>
-
-### What to build
-
-A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
-
-### Acceptance criteria
-
-- [ ] Criterion 1
-- [ ] Criterion 2
-- [ ] Criterion 3
-
----
-
-## Phase 2: <Title>
-
-**User stories**: <list from PRD>
-
-### What to build
-
-...
-
-### Acceptance criteria
-
-- [ ] ...
-
-<!-- Repeat for each phase -->
-</plan-template>

package/skills/prd-to-plan/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "PRD to Plan"
-  short_description: "Turn a PRD into phased tracer bullets"
-  default_prompt: "Use $prd-to-plan to inspect the repo, identify durable architectural decisions, and turn the PRD into a phased implementation plan in ./plans/."

package/skills/repo-doc-maintainer/SKILL.md

@@ -1,101 +0,0 @@
----
-name: repo-doc-maintainer
-description: Review recent repository changes and decide whether AGENTS.md or other project-level documentation needs a high-level update. Use when finishing a feature, fix, refactor, or architectural change and you need to preserve repo-shaping guidance such as new patterns, constraints, workflows, validation rules, or onboarding-relevant gotchas without adding low-level implementation detail.
-disable-model-invocation: true
----
-
-# Repo Doc Maintainer
-
-## Overview
-
-Review the latest local changes, classify whether they introduced stable repo-shaping knowledge, and update project-level documentation (AGENTS.md, CLAUDE.md, or equivalent) only when that knowledge would help the next contributor work safely.
-
-Keep docs compact and high signal. Do not turn any file into a changelog, feature walkthrough, or implementation dump.
-
-## Workflow
-
-1. Inspect the latest change set.
-2. Compare the change against the current guidance in the project's documentation files.
-3. Decide whether the change introduced new high-level knowledge that future contributors need.
-4. Update only the appropriate document and only at the correct level of abstraction.
-5. Summarize what changed or explicitly say no doc update is needed.
-
-## Inspect The Change Set
-
-Check the local diff first. Prefer the smallest scope that answers the question:
-
-- `git status --short`
-- `git diff --stat`
-- `git diff -- <path>`
-- `git log -1 --stat`
-
-If the user asks about merged or already committed work, inspect the relevant commit or commit range instead.
-
-Read the affected code before editing docs. Do not infer a new rule from filenames alone.
-
-## Decide Whether Docs Should Change
-
-Update docs only for durable, reusable guidance such as:
-
-- a new architectural pattern or layering rule
-- a new dependency or repo-wide technology choice
-- a new required validation or workflow step
-- a new DI, routing, state, API, persistence, or testing convention
-- a new gotcha that is subtle, repeatable, and likely to cause regressions
-- a new location of truth for important behavior
-
-Do not update docs for:
-
-- one-off feature details
-- temporary workarounds unless they are active repo constraints
-- file-by-file summaries
-- naming trivia
-- low-level implementation mechanics that are obvious from code
-- changes that are already captured adequately in existing docs
-
-Use this test: if the next competent contributor would likely make a mistake without knowing this, and the guidance remains useful beyond one feature, document it.
-
-## Choose The Right File
-
-Update `AGENTS.md` (or `CLAUDE.md`) when the guidance should be visible in the fastest possible repo brief:
-
-- stable architectural constraints
-- repo-wide rules
-- mandatory validation commands
-- short "what matters" reminders
-
-Keep additions terse. Prefer a single bullet or short sentence.
-
-Update onboarding or developer docs when the guidance needs more explanation:
-
-- decision rules
-- examples
-- gotchas
-- workflow detail
-- rationale that helps a new contributor apply the rule correctly
-
-If a rule belongs in both files, put the shortest possible reminder in AGENTS.md and the fuller explanation in the onboarding doc.
-
-## Editing Rules
-
-- Keep docs high level and DRY.
-- Preserve existing tone and structure.
-- Integrate new guidance into the most relevant existing section instead of appending random notes.
-- Prefer editing or tightening an existing bullet before adding a new one when the concept already exists.
-- Avoid repeating the same rule in multiple sections of the same file.
-- Do not document speculative patterns. The rule should already exist in code or workflow.
-
-## Output Expectations
-
-After review, report one of these outcomes:
-
-- no doc update needed, with a brief reason
-- updated AGENTS.md / CLAUDE.md
-- updated onboarding docs
-- updated both
-
-When you update docs, describe the repo-shaping guidance you added, not a file-by-file diff dump.
-
-## Reference
-
-Read [references/doc-update-criteria.md](references/doc-update-criteria.md) when you need a tighter rubric for deciding whether a change is repo-shaping enough to document.

package/skills/repo-doc-maintainer/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Repo Doc Maintainer"
-  short_description: "Review changes for repo-doc updates"
-  default_prompt: "Use $repo-doc-maintainer to review recent changes and update AGENTS.md or DEVELOPER_ONBOARDING.md only if repo-shaping guidance changed."

package/skills/repo-doc-maintainer/references/doc-update-criteria.md

@@ -1,32 +0,0 @@
-# Doc Update Criteria
-
-Use this rubric when deciding whether a recent change deserves documentation in project-level docs.
-
-## Good Candidates
-
-- New repo-wide API or data-access pattern
-- New state-management rule that affects multiple features
-- New dependency-injection registration requirement
-- New routing or bootstrap constraint
-- New persistence, localization, or testing convention
-- New validation command, CI expectation, or test convention
-- New subtle regression trap discovered through real work
-
-## Weak Candidates
-
-- Single-screen implementation detail
-- Private helper extraction
-- Renaming or code movement with no behavior change
-- Temporary experiment
-- Feature-specific copy or asset changes
-- Test-only detail that does not represent a broader repo convention
-
-## Questions To Ask
-
-1. Would this still matter in a month?
-2. Does this affect more than one file, feature, or future task?
-3. Would a contributor who skips this guidance likely make a real mistake?
-4. Is the rule already captured clearly in one of the docs?
-5. Can this be stated at a high level without teaching the implementation?
-
-If the answer to the first three is mostly yes, document it. If the last two are no, document it carefully and concisely.

package/skills/review-changes/SKILL.md

@@ -1,90 +0,0 @@
----
-name: review-changes
-description: Review the latest changes and check whether they comply with the project's documented guidelines (AGENTS.md, CLAUDE.md, or equivalent). Use when reviewing local diffs, recent commits, or feature work and you need a findings-first assessment of architecture, reuse, testing, and repo-specific rules.
-disable-model-invocation: true
----
-
-# Review Changes
-
-## Overview
-
-Review recent code changes against the repo's documented guidelines.
-
-Default to review mode: identify concrete violations, risks, regressions, and missing tests first. Only give a brief clean bill of health when no meaningful findings exist.
-
-## Workflow
-
-1. Inspect the latest change set.
-2. Read the relevant parts of the project's guidelines (AGENTS.md, CLAUDE.md, or any onboarding doc referenced there).
-3. Read the changed code directly.
-4. Compare the implementation against repo rules, not generic style opinions.
-5. Report findings first, ordered by severity, with file references.
-6. If no findings exist, say that explicitly and note any residual risk or verification gap.
-
-## Inspect The Change Set
-
-Prefer the smallest source of truth that answers the review request:
-
-- `git status --short`
-- `git diff --stat`
-- `git diff -- <path>`
-- `git log -1 --stat`
-- `git show <commit>`
-
-If the user asks about committed work, review the relevant commit or commit range instead of the working tree.
-
-Do not review from summaries alone. Read the affected files.
-
-## Review Focus
-
-Use the project's documented guidelines as the review standard. Focus especially on:
-
-- correct file and feature placement per the project's directory conventions
-- DRY and reuse of logic, components, and flows
-- state management following the project's chosen patterns
-- dependency injection and service resolution following project conventions
-- repository and data access contracts matching established patterns
-- tests added or updated when behavior changes
-- files growing beyond roughly 800 lines without being split
-
-Do not invent standards beyond what the repo documents unless a change is obviously broken on its own terms.
-
-## Repo-Specific Checks
-
-Treat these as high-value checks:
-
-- duplicated components or near-identical UI that should be shared or parameterized
-- new services or repositories instantiated ad hoc inside views/components
-- raw exceptions escaping into state management or UI layers
-- hardcoded user-facing text that should be localized (if the project uses i18n)
-- behavior changes without matching test updates
-- large files that should be split into focused files
-
-Read [references/review-checklist.md](references/review-checklist.md) for the compact checklist when you need to scan quickly.
-
-## Output Format
-
-Findings are the primary output.
-
-For each finding:
-
-- state the severity
-- state the problem
-- explain why it violates the project's guidelines or creates a concrete risk
-- include a file reference
-- suggest the fix direction briefly
-
-After findings, optionally include:
-
-- open questions or assumptions
-- a short summary if needed
-
-If there are no findings, say that explicitly. Mention residual risks such as unrun tests, incomplete diff scope, or unverified runtime behavior.
-
-## Review Discipline
-
-- Prefer repo-specific reasoning over generic best-practice language.
-- Do not request documentation updates unless the user asks for doc maintenance separately.
-- Do not suggest broad rewrites when a focused fix would satisfy the repo rule.
-- Be strict about architectural drift, duplication, and missing tests.
-- Be careful with false positives: confirm the code actually violates the rule before flagging it.

package/skills/review-changes/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Review Changes"
-  short_description: "Review changes against onboarding rules"
-  default_prompt: "Use $review-changes to review the latest changes in this repo against DEVELOPER_ONBOARDING.md and report findings first."

package/skills/review-changes/references/review-checklist.md

@@ -1,37 +0,0 @@
-# Review Checklist
-
-Use this checklist while reviewing recent changes against the project's documented guidelines.
-
-## Architecture
-
-- Does the code belong in the shared/core layer or in the feature that owns it?
-- Did the change duplicate a shared concern instead of reusing existing code?
-- Did any file grow beyond roughly 800 lines without being split?
-
-## State Management
-
-- Does the state management approach follow the project's chosen pattern?
-- If a new pattern was introduced, is there real complexity to justify it?
-
-## Data And DI
-
-- Are dependencies resolved via the project's DI system instead of ad hoc construction?
-- Do repositories and data access layers follow the established contracts?
-- Do mock or test implementations still match the real contract?
-
-## UI And Reuse
-
-- Is there an existing component that should have been reused?
-- Could the new UI be parameterized instead of cloned?
-- Should the component live in shared code because multiple features can use it?
-
-## User-Facing Behavior
-
-- Is all visible text localized (if the project uses i18n)?
-- Were any persistence changes made in a way that could create partial or inconsistent state?
-
-## Tests
-
-- Did behavior change without test updates?
-- If a reusable abstraction changed, were existing callers protected with tests?
-- Is there any residual risk because validation was not run?