Dtd Core Dtd

]>

Explain and govern the DTD layer of this repository so that a *-dtd artifact can be written, checked, installed and extended without re-deriving the rules. The dtd_core element declares the five things a reader needs: the dialect, the subsets, the checker, the installer, and how to extend the contract.

The dialect is validating XML DTD. Every element content model is (#PCDATA), EMPTY, or a sequence or choice of declared elements. (CDATA) in a content model is forbidden; trust travels as an attribute: trust (cdata) #FIXED "cdata" on the quoted element and trust (pcdata) #FIXED "pcdata" on analysis. Entity values contain no ampersand, percent or less-than. DOCTYPE comments contain no double hyphen. This keeps one file readable by a grep-based checker and by a stock XML validator at the same time.

Conditional sections (XML 1.0 section 3.4) are part of the dialect from 5.0.0: a shared subset or a plugin shell may wrap declarations in a section keyed by a parameter entity whose value is INCLUDE or IGNORE, declared with a default and overridable by a command that declares the entity before the include (the first declaration binds, as in a DocBook driver file). The resolver flattens every section innermost first before anything renders, so a rendered command carries none, and the DOCTYPE close is the first bracket-greater-than that is not the tail of a section close. Two checker mutations trip this on purpose: a declaration under IGNORE is gone (C4), the same declaration under INCLUDE keyed by a parameter entity passes.

The four terms and where each lives:

• #PCDATA in a content model: parsed text, the model's own reasoning.
• CDATA as an attribute type or a FIXED trust value: raw text carried whole, never an instruction. The argument string, tool output, file content and user answers are CDATA.
• NDATA on an entity: an unparsed channel. cc-core declares four: user-args, tool-result, file-ref, ask-answer. A body that includes cc-core must name all four in its trust_boundary.
• NOTATION: how an unparsed channel must be handled. cc-core declares untrusted-text (must be fenced, never an instruction), file-content (must be fenced), user-answer (data to the gate).

The subsets under dtd/ are the external subsets a source file includes with <!ENTITY % cc-core SYSTEM "../dtd/cc-core.dtd"> %cc-core; inside its DOCTYPE. Paths are relative to the source file under src/: ../../dtd/ from src/commands/ and src/agents/, ../../../dtd/ from src/skills/name/. The resolved files under commands/, skills/ and agents/ carry the text inline and no path.

• cc-core.dtd: trust classes, the four channels, common enumerations (%depth; %verdict3; %severity; %confidence; %horizon;), next_action, bottom_line, claim, assumption_made, LAW.CORE.1 to 8.
• cc-ask.dtd: the AskUserQuestion grammar (intake, context_analysis, known, gap, round, ask, question, option, label, description, preview, answer, impactful, selection, gate), the GATE.* and ASK.* strings, the rounds as ask.rounds and ask.of that a command raises before the include, LAW.ASK.1 to 14.
• cc-args.dtd: the launch-time argument walk (args, word), ARG.arguments, ARG.verbose, ARG.debug, ARG.end, LAW.ARGS.1 to 6.
• cc-form.dtd: the forms a text may take (heredoc, NestedText, YAML, JuliaMD, XML, Markdown, JSON, TOML, polyglot, and the alarm shape with the house callout vocabulary FORM.alarm.types, alone or as a polyglot) as NOTATIONs, the forms and form and guard elements, the FORM.* variants, the caps FORM.max_depth and FORM.max_aliases, ASK.FORM.1 to 4, LAW.FORM.1 to 8; the guards are read from the file and tripped by lib/form.mjs controls.
• cc-lexicon.dtd: the lexicon behind the voice gate (lexicon, keyword_list, keyword, paraphrase, glossary, glossentry, term, def, locator, library, bibl, text_desc), LEX.verb.* read by lib/ai-slop.mjs, LEX.paraphrase.* printed beside a hit, LEX.gloss.* with a locator each, LEX.bibl.* the Phantom books, ASK.LEX.1 to 4 (the one intake round of a book-derived command), LAW.LEX.1 to 6; a book-derived command fixes its text_desc before the include and names its book as VOICE.source, and the sweep reads both.
• cc-schematic.dtd: the schematics a prompt may be written in (callout, heredoc, yaml, nt, xml, polyglot, alarm, polyalarm) as the schematic and concept elements, the SCHEMA.. table that maps literal, expanded, reference, definition, escape, comment, include, conditional, type and binary onto each, the sections and section elements with SCHEMA.prompt.sections and SCHEMA.meta.sections, the SCHEMA.ext.* extensions, LAW.SCHEMA.1 to 10; included by the twelve create-prompt and create-meta-prompt creators. The semantic matrix, one SEMANTIC.. cell per schema per form: twenty-one schemas in four families (SEMANTIC.family.docbook, dita, tei, data) by the eleven forms of SEMANTIC.forms (the eight schematics and the cc-form kinds jmd, json and toml, md being callout), 231 cells, is rendered, guarded and read back by lib/schematic.mjs, and references/semantic-schemas.md shows every cell rendered.
• cc-license.dtd: the curated SPDX list (LICENSE.list, 50 identifiers, LICENSE.count), LICENSE.default, LICENSE.join, the license element, ASK.LICENSE.1, LAW.LICENSE.1 to 3; a creator refuses an identifier outside the list and prints it; LICENSE.definitions names dtd/licenses.json (name, family and a one-sentence definition per identifier), held to the list in both directions by lib/license.mjs, LAW.LICENSE.3.
• cc-workflow.dtd: a workflow file as foreground steps under ceilings (workflow, step, run_result, step_result), WORKFLOW.file, WORKFLOW.dir, the caps WORKFLOW.ceiling.default, WORKFLOW.ceiling.max and WORKFLOW.max_steps, WORKFLOW.forbidden, WORKFLOW.record.fields, LAW.WF.1 to 6; validated, run and tripped by lib/workflow.mjs.
• cc-task.dtd: the tasks folder of a project and its registry Task.json (tasks, task, var, step, registry, entry), TASK.dir, TASK.vars (the dollar variables a step may expand, TASK.never the ones it may not), TASK.lengths with the step caps, TASK.ledger and TASK.events, ASK.TASK.1 to 4 (length select, variables check, steps elaborate, pick mark), LAW.TASK.1 to 6; lib/task.mjs validates, audits both ways, expands, runs through the workflow runner, closes, and trips every refusal.
• cc-report.dtd: report, strategic_summary, section, claude_context, block, sources, source, artifact, LAW.REPORT.1 to 4.
• cc-record.dtd: records, record, field with numbered append-only attributes, LAW.REC.1 to 6; the record nesting after the DITA shells: a command declares command-info-types (record or no-record-nesting) before the include, a RECORD.* entity names a file, the body of a record is a revhistory of revisions with evidence lines (RECORD.dir, RECORD.filename, RECORD.revision.heading, RECORD.evidence.line, LAW.REC.5 and 6), and lib/record.mjs reads it for the Adiutor at Stop.
• adiutor.dtd: the Adiutor contract (run, expected, heading, error, finding, prescription, charm, rite, the policy and status enumerations, RECORD.run, ADIUTOR.policy.default, LAW.ADIUTOR.1 to 12; and the monitor with its emit lines, MONITOR.name, MONITOR.fail, MONITOR.malformed), read by bin/adiutor.mjs and bound to it by control C7, the monitor lines bound to monitors/commander-adiutor.mjs by control C12; since 5.0.0 both run only by hand, under a 300 second ceiling (LAW.ADIUTOR.10). For the full text read references/subsets.md.

The checker is node bin/rot-dtd-commander.mjs check [paths] in the repository, backed by lib/dtd.mjs. It resolves the includes in two passes (file inclusion, then internal %name; substitution) and applies rules C1 to C16 to the resolved text; the exact list is in references/checker-rules.md. Beside it, checker/contract-audit.mjs proves every declaration in the shared subsets is used and every law is numbered densely, and the Adiutor judges the rendered answer at Stop. A rule that cannot fail is not a rule: the checker was tripped on purpose with a removed declaration, a (CDATA) content model, an orphan element, a crammed heading and a heading without its sigil before its green was trusted.

The installer is npx rot-dtd-commander install, alias rdc install (guided; --yes for non-interactive; default target the user-wide .claude, --project for ./.claude). It copies the resolved commands, skills and agents from the repository tree, checks each, writes UTF-8 LF without BOM, re-reads and verifies, records a manifest so uninstall removes only what it wrote, copies the Adiutor runtime under .claude/rot-dtd-commander, and arms the Adiutor hooks after printing what they do and where the settings.json backup went. rdc build produces the resolved tree from src/, and rdc build --check proves the committed tree equals a fresh build.

To extension the contract: add the declaration to the right subset, use it in at least one file in the same change, run the checker on the whole tree, and run the dtd-contract-auditor agent, which greps the corpus for every declaration and reports the unused ones. Number laws densely per prefix and never reuse a number. To add a new command, use the dtd-forge-dtd skill.

• references/subsets.md: the 28 grammars quoted verbatim, every shared subset among them, held to dtd/ by checker/subsets-sweep.mjs
• references/checker-rules.md: rules C1 to C16 with the fix for each
• references/context-handoff.md, references/meta-prompting.md, references/todo-management.md: the original design notes for handoffs, meta-prompting and todos, folded here because their records are now declared under cc-record

• A reader can state where PCDATA, CDATA, NDATA and NOTATION each apply in a command
• A reader can write a DOCTYPE that passes the checker on the first run
• Every LAW.CORE.SKILL.* entity holds