Founding Principles (the constitution)

These eight principles are normative: every capability in the codebase traces to one or more of them, and any future feature must be justifiable against them.

#	Principle	One-line essence
P1	Determinism in Code, Judgment in Prose	Single-correct-output operations are tested Python in ea-core; only genuine judgment lives in LLM prompts.
P2	The Dependency Rule (One Core, Many Surfaces)	ea-core knows nothing of any host or LLM and never imports an adapter; hosts adapt over a stable CLI contract.
P3	Human-in-the-Loop for Writes	Agents propose; users confirm. Nothing is committed or deleted without explicit review and a verify-before-delete guard.
P4	Methods are Data, Not Skills	Artifact types, methods, and relationships are data (Method Packs) read at runtime — never hardcoded in agents.
P5	Proof-Gated Growth	No second instance of anything ships until the first runs green end-to-end. Depth of proof before breadth.
P6	Deliberate over Convenient	Every configuration default is surfaced and consciously accepted. Nothing is applied silently.
P7	Evolve, Don't Rebuild	Scaling happens by configuration evolution, never re-platforming. Returning respects prior choices and surfaces only what changed.
P8	One Single Source of Truth	A host-agnostic Python ≥3.10 runtime + Tailoring Manifest + typed Artifact Repository are the validated single source of truth.

Precedence: P1 and P2 are load-bearing. When principles appear to conflict, resolve in favor of keeping the core deterministic and host-agnostic.

P1 — Determinism in Code, Judgment in Prose

• Every operation with a single correct output — validation (including compliance checking against data-defined rules), scaffolding, graph computation, reporting, file deletion — is deterministic, tested Python in ea-core.
• Output is byte-for-byte reproducible for identical inputs: stable ordering, no wall-clock or randomness; any timestamp is an injected input, never read internally.
• ea-core never calls, embeds, or depends on an LLM.
• Judgment-bearing behavior — tailoring dialogue, artifact authoring, compliance reasoning — lives only in agent prompts on the surface side. Where a task mixes both (an agent drafts prose, the core validates structure), the deterministic half is a separate core operation the agent invokes via the CLI.

P2 — The Dependency Rule

• ea-core has zero knowledge of any host, surface, or LLM, and never imports an adapter. Dependency direction is strictly surfaces → core.
• The CLI contract (structured JSON on stdout + documented, stable exit codes — reference/cli.md) is the only integration boundary. It is versioned; breaking changes bump the version; adapters declare the version they target.
• Hosts are thin adapters — they translate surface I/O to/from the contract and hold no business logic that belongs in the core. The same core package serves conversational design and headless CI with no surface-specific branches.
• stdout carries machine-readable JSON only; narration and logs go to stderr.

P3 — Human-in-the-Loop for Writes

• Agents only propose changes; applying one requires explicit user confirmation.
• Destructive/mutating operations are dry-run by default, emit the intended effect, and require a content-bound confirmation token to execute.
• No directory or user content is deleted without the tested verify-before-delete guard (fingerprint match before removal).
• Every write/delete returns a structured record sufficient for review and audit.

P4 — Methods are Data, Not Skills

• Artifact types, methods, relationships, and the validation rules are data (Method Packs); validation logic is generic in the core, the rules it enforces come from data.
• Agents read packs at runtime to know how to guide; they hold no hardcoded artifact, method, or field vocabulary — they discover it from the core (scaffold guidance, type show/method show, --list-fields, preset list…).
• Packs are distributable, versioned, schema-validated units; adding a type or method requires no core or agent change — only data.
• Methods are individually selectable; the repo materializes only the active methods and their required types/rules into definitions/ (with pack@version provenance) — never whole packs.
• The set of constraint kinds the evaluator supports is a closed, versioned core capability; packs compose rules only from existing kinds.

P5 — Proof-Gated Growth

• Development moves through explicit gates: a capability counts only when the first instance runs green end-to-end — core operation tested + exercised through the CLI contract + driven by at least one real surface for a complete user-visible task.
• No second instance of any category (archetype, method, agent, surface) is built until the first is proven.
• Each gate records explicit evidence (test run, transcript, or report).

P6 — Deliberate over Convenient

• Every configuration default is explicitly surfaced with its consequence and consciously accepted; nothing is applied silently, and no convenience logic mutates configuration behind the scenes.
• Acceptance is enforced by mechanism, not data: a value reaches the committed source of truth only through a confirmed dry-run-by-default write; the acceptance record is the write audit + version-control history — never an inline accepted flag.
• The domain structure (which domains exist, which types map into them) is org tailoring in the Manifest — org-defined, not pack-defined.

P7 — Evolve, Don't Rebuild

• Scaling a practice (light → heavy archetype) happens through configuration evolution of the Manifest, never re-platforming or discarding the repository.
• Returning to an existing configuration respects prior deliberate choices and surfaces only the delta (the monotonic three-way merge of archetype migration — reference/manifest.md).
• Migration is a deterministic, tested core operation producing a reviewable plan before any write.

P8 — One Single Source of Truth

• The runtime is host-agnostic Python ≥ 3.10; the Tailoring Manifest + typed Artifact Repository are the single validated source of truth. No surface keeps authoritative state outside them.
• Every artifact validates against the active types and Manifest constraints; the core can validate the entire source of truth deterministically, reporting per-scope.
• The repository is plain-text and version-control friendly — it diffs and reviews like code.
• It is partitioned into exactly one Org scope plus multiple coexisting projects; every artifact belongs to exactly one scope, operations run in the context of a named scope (no implicit cross-scope effects), and references are layered: project → Org only, never Org → project, never project → project (reference/repository.md).
• Promotion moves a project artifact into Org as a confirmed, reviewable operation keeping a single authoritative copy. Tailoring is org-level: exactly one Manifest per repository.