Repository navigation
[merge] Step 5: Make OKF type taxonomy pluggable per mode #22
Description
Activity
@claude-opus /opsx:propose
Claude finished @ayrtonvwf's task in 4m 49s —— View job •
claude/issue-22-20260710-1708• Create PR ➔
/opsx:propose — Step 5: Make OKF type taxonomy pluggable per mode
- Gather context (read referenced files)
- Understand the request
- Create OpenSpec change scaffold
- Create artifacts (proposal, design, specs, tasks)
- Validate + commit + push
Created OpenSpec change
pluggable-okf-taxonomyatopenspec/changes/pluggable-okf-taxonomy/. Validation passes (openspec validate→ valid); all 4 artifacts complete.Artifacts
proposal.md— Why/What/Impact. Frames this as a post-merge refactor that keeps the OKF carrier unchanged and makes only thetypetaxonomy per-mode. One modified capability:okf-conformance.specs/okf-conformance/spec.md— delta spec that renames the requirement "Type is inferred from directory via the repository documentation taxonomy" → "…via the mode-selected documentation taxonomy" and modifies it: code mode keeps today's exact types; personal mode gets a personal taxonomy; the prompt contract and stamping pass read the same selected taxonomy.design.md— key decisions:DocTypeTaxonomyas an explicit value (not a mutable global), renameREPO_DOC_TYPES→CODE_DOC_TYPES, minimalPERSONAL_DOC_TYPES(""→Overview,sources→Source,topics→Topic, fallbackNote), andgetTaxonomyForModekeyed onOpenWikiOutputModesince both seams already carry it. Includes risks, migration (pure refactor, deterministic re-stamp), and two open questions.tasks.md— 5 groups: define the abstraction inconstants.ts, thread through the prompt seam, thread through the stamping seam (stampPage→runOkfPass@src/agent/index.ts:243/verifyOkfConformance@src/cli.tsx:918), update/extend tests, and verify.
Key finding
The
code/personalaxis already exists post-merge asOpenWikiRunMode(src/cli.tsx:12), mapped toOpenWikiOutputModeviagetRunModeOutputMode(src/cli.tsx:3880). Both seams already carry mode context (createSystemPromptgetsoutputMode;runOkfPassis called withoutputModein scope), so no new parameter plumbing is needed beyond the taxonomy itself.Ready for implementation. Run
/opsx:applyto start implementing.• Branch:
claude/issue-22-20260710-1708
Part of #17.
Post-merge refactor. Keeps the OKF carrier (frontmatter/index/log/
--okf/--okf-check) unchanged; makes the code-specifictypetaxonomy per-mode. Must come after the merge, which introduces thecode/personalmode axis (fork'sOpenWikiCommandis onlychat|init|updatetoday).Consumers to thread a taxonomy through:
src/constants.ts:274—REPO_DOC_TYPES/REPO_DOC_TYPE_FALLBACK/getRepoDocTypeForDirectory().src/agent/prompt.ts:149—createOkfContractSection()(viacreateSystemPrompt(command,...)).src/agent/okf.ts:326—stampPage()(viarunOkfPass/verifyOkfConformance).test/prompt.test.ts:53,test/constants.test.ts:149.Sketch: define
DocTypeTaxonomy+getDocTypeForDirectory(taxonomy, dir); rename current constant toCODE_DOC_TYPES; addgetTaxonomyForMode(mode); add a minimalpersonaltaxonomy; thread it through the two seams (both already carry mode context).