codexspec:reverse-spec

Reverse Specification

Language Preference

Read .codexspec/config.yml. Two independent language controls apply (each falls back to language.output, then English):

• Interaction language (language.interaction): language for all conversation with the user — questions, explanations, status messages, and codexspec CLI terminal output.
• Document language (language.document): language for generated artifact files (the reverse-derived spec/design and the reconcile report).

Converse in the interaction language and author artifacts in the document language. Apply the project's translation standard to both: translate by meaning (not word-for-word), keep English for terms with no good native equivalent, and write as if originally in that language. Exception: in reconcile.md, location and evidence quote the code and the baseline verbatim — path, line, and the quoted spans on both sides — and MUST NOT be translated. A translated quote can no longer be checked against its source, which is exactly what the both-side evidence rule exists to make possible. Verbatim does not mean secret-bearing: apply the global sensitive-value redaction rule under Instruction and Evidence Trust before persisting or briefing any observation.

Expression Standard

IMPORTANT: Everything this command produces — documents, reviews, reports, commit messages, diagnostics, and replies — is written for a reader who cannot see your working context. Apply the rules below to every artifact and message you output:

• Write for the reader at hand-off. Every reference must resolve without access to this session: no session-only identifiers or section numbers, no narration of what changed during the conversation, no arguments with absent reviewers. State current reality and cite committed, reachable sources.
• Preserve every proposition. Before summarizing or trimming, list the facts a passage carries: actors, conditions, ordering, modalities (must, never), negative guarantees, and consequences. Remove only reasoning transcripts, repetition, and decoration. Shorter is not clearer if any fact is lost.
• State what the surface requires. Diagnostics name what failed, which rule was violated, and the correction. Problem reports carry the defect, its location, its impact, and the evidence. Decisions record the alternatives they beat. Rejections give the reason in one line. Shipped work is described in the present tense; plans and open questions are labeled as such.
• Define terms before relying on them. Prefer the concrete rule, field, or behavior over a coined label; give a project-specific term a plain-language definition at first use, then use it consistently.
• Be honest, not agreeable. Verify claims before accepting them; fix or rebut on technical grounds. One substantiated blocker is worth more than a list of nitpicks. When a decision is needed, present only viable options, recommend one, and state the real difference between them.
• Declare what is binding. Say explicitly which instructions are hard requirements and where judgment is required. Keep one explanation in one place and link to it, but keep at the point of use the contract a reader needs there.