Openspec Reused

Create the reused.md artifact for an OpenSpec change.

This document maps planned functionality to existing code so tasks extend or refactor instead of duplicating. Created after data-model and before tasks.

Input: Change name (kebab-case). If omitted, infer from conversation or list active changes.

Steps

1. Select the change

   • Use provided name, or infer from context
   • If ambiguous: openspec list --json and ask the user

2. Verify prerequisites

   openspec status --change "<name>" --json
   

   • data-model, design, and specs MUST be done
   • If not ready, stop and suggest completing dependencies first

3. Read planning artifacts

   • proposal.md, design.md, data-model.md, delta specs under specs/
   • Extract a checklist of concrete behaviors to implement (UI, API, BFF, enums, downloads, links, status mapping, etc.)

4. Search the codebase (for each checklist item)

   Use multiple strategies:

   • SemanticSearch: "Where is X implemented?", "How does Y work?"
   • Grep: class names, route paths, enum values, API endpoints from specs/design
   • Similar patterns: Link components (*NameLink), resource enrichers, ImportClient methods, status badges, download handlers, policy classes, form requests

   Typical locations in this project:

   • app/Http/Controllers/, app/Services/, app/Clients/
   • resources/js/ (pages, components, hooks)
   • routes/, app/Enums/, app/Policies/
   • tests/ for usage examples

5. Performance reuse checklist (required)

   For each feature or endpoint touched, explicitly check and record findings:

   • N+1 queries: resource/serializer calling repo per item, per-row DB lookups
   • HTTP N+1: per-item HTTP resolve (BFF or client) instead of batch/embed
   • Polling chattiness: frequent list/detail polling of heavy payloads
   • Waterfall fetches: sequential requests on a single page instead of parallel/aggregate
   • Over-fetching: list endpoints returning large fields unused by UI
   • Duplicate work: repeated computation/lookups across list → show flows

6. Classify each finding

   Action	When
   reuse	Existing code satisfies the requirement with no change
   extend	Existing module/class is the right place to add behavior
   refactor	Two similar implementations exist — extract shared piece first
   new	No suitable code; justify in Gaps

7. Get artifact instructions

   openspec instructions reused --change "<name>" --json
   

   Write to resolvedOutputPath using the template.

8. Write reused.md

   • One Findings block per spec requirement or design decision
   • Table rows: Action, Path, Symbol (Class::method or component name), Notes
   • Recommendation per block with clear next step
   • Gaps for items marked new
   • Task Hints: bullet list mapping reuse decisions → task wording (e.g. "Extend SupplierNameLink → create PresetNameLink with same props pattern")

9. Validate

   openspec status --change "<name>"
   openspec schema validate spec-driven
   

Output

Summarize:

• Change name and path to reused.md
• Reuse vs extend vs new counts
• Top 2–3 highest-impact reuse opportunities
• Next step: create tasks.md — tasks must reference paths from reused.md

Guardrails

• Every path must be real — verify files exist before listing
• Do not recommend new when extend is possible on an existing class
• Prefer extending BFF enrichers, shared components, and clients over parallel copies
• If design proposes new code but reuse audit finds equivalent — flag in Task Hints and suggest design update
• Write prose in Russian; keep paths, symbols, and enum literals in English as in code