Scope
The senior-engineering centerpiece of v2.4.0. Change /own:done to mutate tasks.html via data-attribute exact-string Edit (the Option D contract), and change /own:status to count progress via text scan with no HTML parser.
This is the LinkedIn / interview-story PR for the whole migration.
Dependencies
Before you scope further — read these
#9 — locked architecture decisions. Decision 1 (Option D) is the most important one for this PR.#10 core/templates/html/tasks.html.template — read the SEMANTIC CONTRACT block in the inline HTML comments at the top of the file. It documents the exact-string transforms required:
/own:done mutation pair (Edit tool, exact-string, replace_all=false):
Before: data-task-id=\"X.Y\" data-status=\"pending\"
After: data-task-id=\"X.Y\" data-status=\"completed\"
Also: <input type=\"checkbox\" aria-label=\"$LABEL\" />
→ <input type=\"checkbox\" checked aria-label=\"$LABEL\" />
/own:status counting (text scan, no parser):
Total = count of data-task-id=\"
Completed = count of data-status=\"completed\"
Progress = (completed / total) * 100
- Memory:
feedback_pr1_runtime_lessons.md — the no-assumptions design principle. PR 4's flow has zero ambiguity: text scan → Edit tool → done. No "detect available, invoke skill" complexity anywhere.
- Current
.claude/commands/own/done.md and status.md — replace their tasks.md regex/checkbox logic with HTML versions.
Hard constraints (do not violate)
- No external HTML parser. Cheerio, BeautifulSoup, jsdom — all OFF the table. Claude's Edit tool is the only mutation mechanism.
- Validate before mutate. Every mutation must first confirm
<body data-document-type=\"tasks\">. If not, refuse — could be wrong file.
- Edit tool with
replace_all=false. The data-task-id values are unique per task block, so single replacements work. Bulk replace would be wrong if two tasks had the same description.
- Phase completion side effect. When the last task in a phase completes (all
data-task-id=\"N.*\" for that N have data-status=\"completed\"), update roadmap.html: change that phase's <section> data-status=\"incomplete\" to \"complete\". Same Edit-tool exact-string pattern.
/own:status text-count must not rely on parsing. Just grep -c semantics. The contract guarantees it works on malformed HTML too.- DO NOT modify the data- contract.* The Option D attributes are now part of OwnYourCode's public ABI for v2.4.0 — projects in the wild depend on them.
- Update
[Unreleased] block in CHANGELOG.
Suggested implementation flow
- Spin up
/tmp/owntest-pr4/ with PR 3's main: install → /own:init → /own:feature → producing tasks.html.
- Read tasks.html structure and the inline contract comments.
- Implement
/own:done task completion: find by description match → identify data-task-id → Edit-tool replace the data-status + checkbox.
- Implement
/own:status progress: grep counts → percentage.
- Test the phase-completion side effect: complete all tasks in a phase, verify
roadmap.html phase data-status flips to \"complete\".
- Edge case: what if user has 2 tasks with identical descriptions?
data-task-id saves you — use it for the user prompt ("which task?").
- Update CHANGELOG. Run
/own:done (meta — you're using the feature you just built to mark this PR's tasks complete).
LinkedIn post material
After this PR ships, this is the headline:
"How I built spec-mutation into a Markdown-replaced workflow without adding a parser dependency. Data attributes + Claude's existing Edit tool = the entire engine. Zero external dependencies, scales with model capability instead of compensating for current weakness."
Open this issue's PR with title
feat(v2.4.0): /own:done + /own:status mutate/parse tasks.html via Option D (PR 4/5)
Refs #9 · Centerpiece of #10
Scope
The senior-engineering centerpiece of v2.4.0. Change
/own:doneto mutatetasks.htmlvia data-attribute exact-string Edit (the Option D contract), and change/own:statusto count progress via text scan with no HTML parser.This is the LinkedIn / interview-story PR for the whole migration.
Dependencies
tasks.htmlwith thedata-task-idvalues this PR will mutate.Before you scope further — read these
#9— locked architecture decisions. Decision 1 (Option D) is the most important one for this PR.#10core/templates/html/tasks.html.template— read the SEMANTIC CONTRACT block in the inline HTML comments at the top of the file. It documents the exact-string transforms required:feedback_pr1_runtime_lessons.md— the no-assumptions design principle. PR 4's flow has zero ambiguity: text scan → Edit tool → done. No "detect available, invoke skill" complexity anywhere..claude/commands/own/done.mdandstatus.md— replace theirtasks.mdregex/checkbox logic with HTML versions.Hard constraints (do not violate)
<body data-document-type=\"tasks\">. If not, refuse — could be wrong file.replace_all=false. The data-task-id values are unique per task block, so single replacements work. Bulk replace would be wrong if two tasks had the same description.data-task-id=\"N.*\"for that N havedata-status=\"completed\"), updateroadmap.html: change that phase's<section>data-status=\"incomplete\"to\"complete\". Same Edit-tool exact-string pattern./own:statustext-count must not rely on parsing. Justgrep -csemantics. The contract guarantees it works on malformed HTML too.[Unreleased]block in CHANGELOG.Suggested implementation flow
/tmp/owntest-pr4/with PR 3's main: install →/own:init→/own:feature→ producing tasks.html./own:donetask completion: find by description match → identifydata-task-id→ Edit-tool replace the data-status + checkbox./own:statusprogress: grep counts → percentage.roadmap.htmlphasedata-statusflips to\"complete\".data-task-idsaves you — use it for the user prompt ("which task?")./own:done(meta — you're using the feature you just built to mark this PR's tasks complete).LinkedIn post material
After this PR ships, this is the headline:
Open this issue's PR with title
feat(v2.4.0): /own:done + /own:status mutate/parse tasks.html via Option D (PR 4/5)Refs #9 · Centerpiece of #10