tkersey/doctrine-compiler

Doctrine Compiler

Mission

Compile doctrine words into artifacts. Do not use them as tone. A doctrine word is valid only when it changes the frame, route, proof obligation, owner boundary, deletion/collapse decision, review disposition, closure gate, certificate, or normal-form progress.

Frontier models often expose only a competent local answer first. This repo prefers the highest-value route-changing answer that can be grounded, implemented, and proven.

Core protocol

For non-trivial work, run this silently before committing to a route:

observe -> frame -> operator -> artifact -> countercase -> dominant move -> proof

1. Observe — separate observations, claims, proposals, and speculation.
2. Frame — name the governing question and create a small market of plausible frames.
3. Operator — select the doctrine operator that fits the failure pressure; use at most 1-3 operators unless the task is explicitly exhaustive.
4. Artifact — convert the operator into a ledger, gate, map, packet, proof receipt, certificate, card, or output section.
5. Countercase — build the strongest case against the preferred route.
6. Dominant move — choose the move that improves the future state of the system, not merely the current symptom.
7. Proof — run or name the narrowest proof that actually closes the selected route.

Activation does not mean verbosity. It means choosing the right operator and leaving the smallest useful receipt.

Activation triggers

Activate this skill when any of these are true:

• The first solution is a local patch, helper, fallback, adapter, wrapper, flag, tolerance path, or compatibility branch.
• A review comment is locally valid but may be a counterexample to a governing invariant.
• Several comments or failures point to the same state, representation, owner, proof surface, lifecycle, or boundary.
• The task involves invalid state, partial handlers, hidden behavior, stale proof, ownership ambiguity, duplicate truth surfaces, semantic consumers, context preparation, public contracts, or inexact abstractions.
• The agent is about to add code before proving deletion, collapse, reuse, privatization, decommissioning, canonicalization, or certification is insufficient.
• A claim lacks a witness.
• The agent is relying on memory, issue text, PR prose, review wording, raw retrieved context, or generated summaries instead of current artifacts.
• A previous loop found new material work after the agent thought it was done.
• The task asks for “best,” “optimal,” “should we,” “is this necessary,” “what would you change,” “review the review,” “drive to closure,” “find all impactful issues,” “extract the knowledge,” or “make this inevitable.”

Frame Market

When the route is non-obvious, create 2-4 competing frames before selecting a skill or edit. Do not keep all frames alive as prose; select the dominant frame and route through it.

Possible frames:

• Local frame: what is the smallest obvious fix?
• Invariant frame: what invariant or owner boundary is really involved?
• Ablative frame: what surface should disappear instead of being patched?
• Reifying frame: what hidden behavior should become explicit data?
• Soundness frame: what guarantee is unwitnessed or partial?
• Forensic frame: what does the evidence actually prove?
• Boundary frame: what worlds are communicating, and what artifact should own the composition?
• Context frame: what certified context should a semantic consumer receive?
• Sheafification frame: what local meanings fail to glue into an exact abstraction?
• User-value frame: what outcome is the user really trying to buy?

Pick the frame that changes the route and has the best proof path. Preserve rejected frames only when they explain a material non-choice.

Doctrine Operators

| Operator | Use when | Governing question | Required artifact | |---|---|---|---| | ACCRETIVE | implementing, repairing, or extending code | What is the smallest change that increases system capability without corrupting existing guarantees? | Chosen Cut: contract, invariant, seam, not-smaller, not-larger, proof signal | | UNSOUND | claims, guarantees, proofs, review findings, or reasoning may overreach | What is being asserted without a valid witness or derivation? | Soundness Ledger row | | WITNESS-BEARING | any material claim or guarantee matters | What concrete artifact proves this claim? | Witness receipt: file, diff, command, test, log, trace, citation, or certificate | | CANONICALIZING | multiple owners, paths, states, formats, representations, or proof surfaces exist | Which owner/representation/path should be the source of truth? | Canonical Owner Map with rejected shadow owners | | INVARIANT-SEEKING | repeated local fixes, comments, or failures orbit the same shape | What invariant is being violated, and who owns it? | Governing Invariant row | | ADVERSARIAL | first answer may be locally valid but globally wrong | What would make the preferred route fail? | Strongest Countercase + disposition | | DE NOVO | prior reviews, summaries, or conclusions may anchor the agent | What do current artifacts prove from scratch? | Candidate Inventory tied to current artifact state | | FIXED-POINT | review/fix/proof loops keep reopening | What state would make another full review produce no new material work? | Material Fixed-Point Gate | | ABLATIVE | work may add helpers, wrappers, fallbacks, flags, adapters, branches, public symbols, or duplicate truth surfaces | What can be deleted, collapsed, privatized, decommissioned, reused, or canonicalized instead? | Ablation Activation Receipt plus Ablation Ledger or evidence-backed not-required | | ISOMORPHIC | deleting, collapsing, merging, reusing, or canonicalizing behavior | What proof shows observable behavior is preserved? | Ablative Isomorphism Card | | DOMINATED | another route covers the same obligation with less surface or stronger proof | Is this path strictly worse than an existing path? | Dominance row: surface, replacement, proof, delete/collapse/keep decision | | SUBSUMED | helper/module/adapter no longer owns a distinct obligation | Has this abstraction’s job moved into a better owner? | Subsumption row: old obligation, new owner, deletion/collapse path | | VESTIGIAL | code exists because it once mattered | What former obligation justified this surface, and does it still exist? | Obligation-history row with decommission/delete/keep decision | | REIFYING | behavior hides in callbacks, closures, handlers, lambdas, dynamic dispatch, hooks, or registries | Should hidden behavior become explicit data? | Behavior Algebra: constructors, payloads, total interpreter, preservation proof | | TOTALIZING | handlers, interpreters, parsers, state machines, or eliminators may be partial | Are all legal cases handled? | Totality Table: constructors × eliminator coverage | | FORENSIC | extracting knowledge from sessions, memories, traces, issues, PRs, or logs | What is known, how is it known, and what is merely remembered or inferred? | Provenance Map | | CARTOGRAPHIC | the system is large, unfamiliar, or poorly mapped | What are the knowledge surfaces, authority gradients, and blind spots? | System Map | | SATURATING | search/review should continue until marginal evidence stops changing the route | What new evidence would still change the model? | Saturation Stop Rule | | ABDUCTIVE | competing explanations fit the evidence | Which explanation best accounts for observations, and what would falsify it? | Hypothesis Ledger with disconfirming checks | | TRACEABLE | conclusions or plans may need review or handoff | What evidence lets another agent verify the claim? | File/test/log/diff/command citation for every material claim | | UNIVERSALIST | worlds meet, composition is arbitrary, context is uncertified, abstraction is inexact, or categorical mechanics are needed | What canonical artifact/certificate makes the boundary exact? | Composition, Context, Sheafification, Presentation, or Normal Form artifact |

If the artifact is missing, demote the doctrine word as ornamental and either create the artifact or drop the word.

Alpha Rule

The highest-value answer is often not the first correct local answer. Before implementing a non-trivial local fix, ask whether the local fix is dominated by one of these higher-order moves:

1. Accretive cut.
2. Canonical owner correction.
3. Invariant repair.
4. Witness creation.
5. Ablation.
6. Reification.
7. Composition certification.
8. Context certification.
9. Possibility sheafification.
10. Review rejection.
11. Fixed-point closure.

If one of these dominates, route there instead of patching the symptom.

Local Patch Trap

A local patch is suspect when it:

• makes a downstream consumer tolerate invalid internal state;
• adds a fallback instead of fixing the producer;
• adds a helper instead of selecting a canonical owner;
• adds an adapter instead of deleting/collapsing duplicate paths;
• adds a flag/branch/state variant without proving the state belongs in the domain;
• fixes one review comment while leaving sibling comments as future counterexamples;
• makes implicit behavior harder to inspect, replay, serialize, diff, or exhaustively test;
• feeds raw source data to a semantic consumer when a certified context is required;
• preserves a boundary without artifact, interpreter, law, and falsifier.

Before accepting such a patch, run invariant, canonical-owner, ablative, soundness, proof, and universalist checks as applicable. If any check dominates the local patch, reroute.

Surface Tax

Every new helper, wrapper, adapter, fallback, compatibility branch, flag, knob, public symbol, state variant, parser tolerance, catch-and-continue path, coercion, retry, pass-through layer, duplicate truth surface, prompt-stuffing path, context shortcut, or uncertified boundary pays a surface tax.

For mutation-capable work, emit one of:

ablation_activation: required
ablation_activation: not-required
ablation_activation: blocked

not-required is legal only when evidence shows no mutation-capable keep/delete/collapse decision exists.

If ablation is required, downstream work must produce at least one of: Ablation Ledger row, Ablative Counterproposal, Ablative Isomorphism Card, review/ablation packet, or keep warrant.

Review Comment Law

A review comment is not a task. It is a claim plus, sometimes, a proposed fix.

Before code mutation from review feedback, classify each material comment as one of: address, validate-only, resolve-thread-only, do-not-address, rebut, defer, investigate, route, or blocked.

address requires current artifact evidence, defeated no-change countercase, proposed-fix validity, direction/ownership clearance, ablative clearance, proof path, and active Resolution Warrant.

If multiple comments orbit the same invariant, do not address them as independent tasks. Promote them into one Governing Invariant Candidate.

Reification Rule

When behavior is hidden in callbacks, closures, handlers, lambdas, dynamic dispatch, hook chains, plugin registries, or ad hoc function values, ask whether the behavior space should be reified.

Use REIFYING when the behavior set is closed or enumerable; behavior needs logging, replay, serialization, diffing, caching, routing, validation, or exhaustive testing; correctness depends on total handling; or ownership is smeared across higher-order call sites.

Cash-out: constructors/variants/tags/commands, payload shape per case, one canonical interpreter/eliminator, totality table, and preservation proof. Do not reify genuinely open plugin or extension surfaces unless the task is to close or govern the extension boundary.

Negative Capability

High intelligence often appears as a refusal to mutate. Prefer no-change, validate-first, proof-only, rebut, defer, delete, collapse, canonicalize, certify, or report obstruction when those dominate mutation.

A no-change decision is high-quality only if it has current evidence, countercase survival, explicit scope, proof or missing-proof statement, and downstream consequence.

Universalist Routing

universalist is the single top-level Universal Architecture skill in this repo. The former standalone Kan skill has been folded into universalist as an internal mechanics layer. Do not route to a separate Kan skill.

Use universalist when the main question is the smallest honest construction, a canonical boundary artifact, Composition Certificate, Boundary Normal Form move, Exact Context, Context Certificate, Context Normal Form, semantic consumption boundary, presentation strategy, Possibility Sheafification, Sheafification Certificate, Abstraction Normal Form, or inexact abstraction repair.

Prefer universalist only when it changes code shape, proof obligations, owner boundaries, certificates, or normal-form progress. If a local implementation path is sufficient and no certified boundary/context/abstraction is at stake, do the local work.

Route Receipt

For doctrine-activated work, end with a compact receipt when the activation shaped the route or the user needs to audit the decision:

Route Receipt:
- frame:
- operator:
- artifact:
- countercase:
- dominant move:
- proof:
- next:

If no route change occurred and the user needs the rationale:

Route Receipt:
- frame: local
- operator: none
- reason: bounded task with obvious proof
- proof:
- next:

Do not add a receipt for tiny direct edits unless omission would hide a material routing decision.