feat(v2.4.0): PR 3/5 — /own:feature writes HTML output + parses roadmap.html for phase detection

[DanielPodolsky]

Scope

Change /own:feature to write spec.html, design.html, and tasks.html instead of .md files, AND replace its current roadmap.md regex-based phase detection with a text-scan against roadmap.html using the data attributes shipped in PR 1.

Dependencies

• ✅ PR 1 (feat(v2.4.0): HTML SDD foundation — templates, theming, plugin integration (PR 1/5) #10) — provides templates
• ⛓ PR 2 (feat(v2.4.0): PR 2/5 — /own:init Phase 6 writes HTML output (mission, stack, roadmap) #11) must be merged first. PR 2 writes roadmap.html; without it this PR's phase detection has nothing to read.

Before you scope further — read these

1. #9 — locked architecture decisions.
2. #10 and #11 (merged) — foundation + roadmap.html writer. Specifically:
   • core/templates/html/spec.html.template (with user-story / acceptance-criteria / edge-cases / out-of-scope sections)
   • core/templates/html/design.html.template (with trade-off / architecture-diagram / open-questions)
   • core/templates/html/tasks.html.template — read its inline contract comments carefully, this is the Option D canonical exemplar that PR 4 will mutate
   • The actual roadmap.html produced by PR 2 — confirm data-phase-number, data-phase-name, data-status are on every phase
3. .claude/commands/own/feature.md current implementation — its existing roadmap.md regex/auto-detection logic is what you replace.
4. Memory: feedback_pr1_runtime_lessons.md — the fallback-first principle. No mid-flow plugin invocation.

Hard constraints (do not violate)

• Pure visualization. Same content as MD spec — just HTML rendering.
• theme.css path for specs/active/phase-*/*.html is ../../../.theme/theme.css (3 levels up). Templates already have this.
• tasks.html data-task-id values must be UNIQUE per file and stable (e.g., 1.1, 1.2, 2.1). PR 4's /own:done mutates by this exact attribute via Edit tool exact-string match.
• tasks.html data-status must be initialized as \"pending\" (not \"incomplete\" — that's for phases) for each new task.
• Phase detection logic for roadmap.html (text scan, no parser):
  1. Read ownyourcode/product/roadmap.html
  2. Find first occurrence of data-status=\"incomplete\"
  3. From the same <section> extract data-phase-number and data-phase-name
  4. Create ownyourcode/specs/active/phase-{number}-{name}/
• DO NOT mutate roadmap.html in this PR. Phase status updates happen at PR 4 boundary when all tasks in a phase complete.
• The "4 design layouts" pattern from Thariq is OUT OF SCOPE. design.html is technical software design, not UI mockups. (See #9 constraints.)
• Update [Unreleased] block in CHANGELOG.

Suggested implementation flow

1. Re-run /tmp/owntest-pr3/ with PR 2's main: install → /own:init (produces roadmap.html).
2. Read the 3 per-feature templates and the produced roadmap.html.
3. Implement phase detection: text scan for data-status=\"incomplete\" + extract phase-number/name.
4. Implement spec.html / design.html / tasks.html generation from templates.
5. Test: /own:feature should auto-detect Phase 1, create specs/active/phase-1-foundation/ with 3 HTML files.
6. Verify data-task-id values are unique and stable.
7. Verify HTML renders in browser (relative theme.css path resolves).
8. Update CHANGELOG. Run /own:done.

Open this issue's PR with title

feat(v2.4.0): /own:feature writes spec/design/tasks as HTML + parses roadmap.html (PR 3/5)

Refs #9 · Builds on #10, #11