Dtd Forge Dtd

%cc-core; %cc-ask; %cc-cache; ]>

Produce one *-dtd command file that passes rdc check, either new (from a philosophy, a book, a method) or converted (from an existing command). The forge_session root declares the steps: an intake that fixes the shape, a design, a spec entry, the forged file, and its verification.

1. intake: read the request. Ask, with AskUserQuestion and at most four questions, only what is open: the source (a method, a book, an existing file), the shape of the answer (a fixed section order, a chain with ids, a roster, a record), whether the command should gate on AskUserQuestion during its own run, and the allowed tools. Skip anything the request already states. The gate that follows offers GATE.save beside start, more, add and impactful, and a run that was saved resumes from its cache before it asks (LAW.CACHE.1, LAW.CACHE.3).
2. design: write the grammar first. Name the root (a noun, lowercase, underscores). List the children in the order the answer reads, with cardinality (?, *, +, or exactly one). Decide attributes: enumerations for verdicts, ID/IDREF/IDREFS for anything that must point at something else, %confidence; wherever a claim can be measured. Write two to four laws that constrain the answer, numbered from 1 under a new prefix; a law that restates the objective is not a law.
3. spec_entry: write the entry. For a new command add it to a spec module shaped like references/spec-shape.md with new: true, to, root, model, attlist, laws, objective (naming the source honestly in one sentence), process, map (every declared element in backticks), template, success. For a conversion add it to dtd/forge-spec.json with from, to, root, model, attlist, laws, map.
4. forged: run node bin/rot-dtd-commander.mjs forge <spec> <name> from the repository root, with a 120 second ceiling, and read the file it wrote.
5. verification: the forge command already runs the checker; quote its OK or FAIL line. Then run the command once in a session with a fixture argument and read rdc ledger --last 1: the Adiutor's verdict on the rendered answer (headings, order, dangling ids) is the instrument, and a pass that was never seen failing is not yet trusted.

Render forge_session as: the intake questions and answers, the design as a DOCTYPE block, the spec entry path and kind, the forged path, and the verification line with checker and xml results. Every element in the design must appear in the map; every map row must name a declared element.

• references/spec-shape.md: the fields of a spec entry and the file the forge produces from it

• The grammar was written before the prose
• The checker passed on the forged file
• Every LAW.FORGE.* entity holds