/Development

name: Development
metadata:
  short-description: "Builds, tests, modifies, and checks up on software against its ISA, keeping the code and its ISA criteria in agreement."
version: 1.4.3
description: Builds, tests, modifies and checks up on software against its ISA, from a one-file change to a giant system. Build turns intent into ISA criteria and makes them pass; Test proves the ISA is well formed, matches the code, and every criterion's Assay eval passes; Modify changes criteria first, then code; Checkup joins the ISA with production, Vigil, Errata and Achilles, says why each red criterion is red, and repairs the ISA. Each run is sized to the ask: small work inline, wide work a workflow. USE WHEN build an app, site, game, tool, CLI or pipeline, start a new project, implement or change a feature, fix a bug in an app, test the app, is the code in sync with the ISA, run the app evals, catch up an old repo into an ISA, health check, checkup, why are these ISCs red, audit the ISA, sync the ISA with production. NOT FOR editing an ISA's articulation alone (ISA), eval or judge design (Assay), new skills (CreateSkill), workflow definitions (Workflows), slides, images, Visualize, deploying (the project deploy command).
evals:
  manual:
    reason: "whether Build produces an ISA the principal accepts, and whether runs stay fast, can only be judged on real work"
    falsifier: "the principal rejects the ISA from a real Build as a wrong articulation, or a small change takes minutes of ceremony before code"

Development

**Contents:** Ideal State · Intent Routing · Data & Config · Acceptance (output contract) · Safety gates · Execution · Tools · Gotchas · Examples

The thin actor between an ISA and its code. The ISA holds the rigor: what done means, every criterion, every criterion's eval. Assay is how each criterion is verified, and the only eval system a build may use (`LIFEOS/DOCUMENTATION/Assay/AssaySystem.md` § One eval system), at the cheapest honest tier: a code assert when the criterion is literal, a judgment-layer question when it needs reading, a judge only when neither can answer, the principal for taste. Development builds, tests and modifies until the code and the ISA agree.

Ideal State

• At the end of every run the code and its ISA agree: every criterion in scope carries an eval at the cheapest honest Assay tier, and its result is recorded in the ISA.
• Criteria change before the code they govern; only a trivial change (a typo, a value, an obvious one-liner) skips the ISA.
• Nothing the principal will see or use is called done until acceptance against a reference they approved has passed (§ Acceptance); passing tests are the builder's signal, not the done signal.
• The report on such work opens with the acceptance verdict and its capture paths. The captures show the whole thing working the way the principal meets it: a page renders top to bottom at desktop and phone widths and looks like the reference. A report without a passing verdict, and without the principal's waiver, does not call the work done, fixed or shipped.
• The criteria are the only artifact written before the code.
• Nothing here deploys or writes production data; the project's gated deploy command ships.

Intent Routing

| Intent | Trigger | File | |--------|---------|------| | **Build** | new app, new feature, "build this", an existing repo with no ISA | `Intents/Build.md` | | **Test** | "test the app", "is it in sync", "run the evals", a check before deploy | `Intents/Test.md` | | **Modify** | change, fix or remove behavior in an app that has an ISA | `Intents/Modify.md` | | **Checkup** | "health check", "checkup", "why are these ISCs red", "get everything in sync", "audit the ISA" | `Intents/Checkup.md` |

| File | Read when | |------|-----------| | `References/Guards.md` | a guard refuses an edit or a builder, or you need to know whether an edit is checked against an ISA | | `References/Inventory.md` | reading `Inventory.ts` or `sync` output, or the code section of a `Checkup.ts` bundle | | `References/Tools.md` | a run needs a tool's full flags, output or exit codes, or is reading ISAGate's `bundled-claim` finding | | `References/Sizing.md` | questioning a run's tier, or checking whether sizing holds on the shape scoreboard |

Data & Config

User customizations at `${CLAUDE_CONFIG_DIR:-$HOME/.claude}/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Development/` (`PREFERENCES.md` and any files it lists) override the defaults when that directory exists.

Acceptance (output contract)

• **Done means acceptance passed:** the work was met the way the principal will meet it, compared to the reference and their words, and passed, with the captures. Criteria and tests are the builder's tools, not the done signal. Only the principal waives acceptance. (2026-10-07: a product page reached production broken while its whole test suite passed. `IsaCheck.ts acceptance` checks the recorded verdict at run end; the deploy path does not check it, `References/Guards.md`.)
• The reference is the existing thing the work should be like (looked for in LifeOS and the project first), or a rough mock or sample output when nothing exists. The principal approves it before code is written, and the ISA links it.

• **How deep acceptance goes follows what the principal will meet** (principal, 2026-10-12: speed is part of the experience). A rendered page, app UI or user-facing flow, anything deployed, and anything on a `high-risk-path` get the fresh agent below. A CLI, hook, internal tool or doctrine change is accepted by the builder's recorded run of the real command the principal would run, its output captured and compared with their words; that run is the verdict recorded under `## Status`.

For the first kind: a fresh, non-forked agent of a lineage other than the builder's when one is available (Astra for Claude-built work). Its brief carries exactly four things and nothing else, no criteria, diff, test results or builder notes:

1. T