The Project Agent Scaffold · v3.0

An Engineering Operating System

Distilled from 750+ hours of hands-on production engineering with these agents in the loop,
compared to 150+ other skills & frameworks and used over 10 million tokens in this setup

Author: Martin Molenkamp

A reusable, project-agnostic shell for building software with a human Orchestrator and two agent functions, an Architect and an Engineer. This is the framework, not the product: a constitution, a rules library, a skills library, a sub-agent roster, a coordination pair (an evidence-gated ledger plus an append-only log), and a clean CI spine. Drop it into any project, fill the placeholders, and the agents compound instead of resetting every session. From a production multi-tenant AI-SaaS build, with the product, vendors and proprietary methods stripped out.

Quickstart

  1. Copy project-agent-scaffold/ into your repo root. Ask your LLM to fill in the placeholders, or grep -r "{{" . yourself (the table is in ADOPT.md); delete what does not apply.
  2. Create two worktrees, one per agent function. Orca makes this one click per worktree; plain git worktree add ../design design/agent works too. The Engineer works the main tree on per-row branches; the Architect gets its own worktree on the design branch.
  3. Start the Engineer in its worktree: Claude Code or any other agentic coding agent (for a non-Claude harness, rename CLAUDE.md to its root file). The constitution loads itself; type check handoff.
  4. Start the Architect in the design worktree, same constitution. The reference setup runs both functions as CLI agents inside Orca, one worktree each; any harness with file access works.
  5. Ask either agent: run skills/validate-scaffold-to-stack, the two-way coverage diff between the scaffold and your stack.
  6. First feature: tell the Architect brainstorm <your idea>. The operating model carries it from there: spec, bind, ledger rows, ship.

You are the Orchestrator: resolve blocking questions, bind specs, approve destructive actions, merge PRs. Everything else moves through the ledger.

1The operating model: three functions, one human at the gates

Why: two agent functions that both touch everything drift apart; clear authority boundaries plus one shared log keep them coherent over months. The human is not a relay; the shared file is the channel.

The three functions, and where each runs

This scaffold's reference setup uses two different tools, bridged by git. The names are placeholders; the topology is the point.

RoleRuns inOwns
ArchitectA second CLI agent inside Orca (reference setup) or any harness with file access, in its own worktree on its own design branchThe constitution, specs, wireframes, the ledger and the design-side log entries. Commits its own branch, scoped to design paths; never source, never the integration branch, never a merge.
EngineerClaude Code, inside Orca, one worktree per goalSource code, migrations, all git for both sides, the build-side handoff entries. Commits and opens PRs, and commits the Architect's handoff/specs (the Architect has no git).
Orchestrator (the human)Chats with both agentsThe four gates, given in chat. Routes and approves; never touches git, the Engineer enacts every git action (commits, merges) after the human's approval.
The bridge is git, not a person, and it runs both ways. The Architect commits its own branch; the Engineer merges that branch into the integration branch when it needs the specs, and Orca's Build worktrees branch from there. Separate worktrees are non-negotiable: two working copies over one .git, so a checkout or reset on the build side can never revert uncommitted design work. The price is two copies of the ledger, which each side reconciles against the other before writing (CI checks d and e). Neither agent needs the other online; the repo is the rendezvous.

Spinning up the Engineer in Orca, wired to the handoff

Claude Code auto-loads CLAUDE.md from the repo root, so the constitution ships as CLAUDE.md and every Orca worktree picks it up with zero setup. The wiring is four files in the repo:

# repo root, read automatically by every Claude Code agent in every worktree
CLAUDE.md                      # the constitution; first line tells the agent to read the handoff
operating-model/STATE.md       # the ledger it picks its @build rows from
.claude/commands/              # slash commands: /check-handoff  /check-board  /ship
.claude/agents/                # the specialist sub-agents invoked at gates

# the loop, per worktree:
# 1. Orca: new worktree for goal G1.2 (one node = one worktree = one branch)
# 2. in its terminal:  claude   then:  /check-handoff
# 3. agent reads the tree, claims its @build nodes, works the goal-batch
# 4. agent appends a build-side handoff entry + opens a PR  (a human gate)
# 5. you review the diff in Orca, merge; the design side reads the entry next session

The /check-handoff command is a short prompt file that says: read operating-model/STATE.md, find open rows owned by @build, pick up the lowest-numbered unblocked one and its goal-batch, reconcile against the other tree's copy before writing, and reply in the log with what you are taking. That single command is the whole "correct handoff" entry point; the constitution makes reading the handoff the first action of every session anyway.

Making context visible, and keeping dialogue two-way added

An agent's context is invisible: the human cannot see which agent is replying, whether it loaded the rules, or whether it pushed back. Two cheap conventions surface it.

Context markers. Every agent reply opens with a marker, stacked space-separated, in the chat reply only (never in committed prose, where the no-inline-emoji house style still binds). It makes the operating state scannable at a glance.

MarkerMeans
🟡the Architect is speaking
🔵the Engineer is speaking
🍀constitution + the rules matching this surface were read this session
♻️a rule or spec was just re-read mid-session
boundary held: refused a cross-line ask and offered the right-side artifact instead
🚩flagging a blocking-class question or a contradiction in the ask

Dialogue habits. Two reflexes keep the human and the agents in dialogue rather than one dictating. "You do it": when an agent asks the human to run, test or deploy-prep something, the default answer is "you do it", the agent has broad tool access and usually finds a way, which reinforces remote-only execution. Reverse the direction: when an agent hands the human a decision, the human flips it ("show me a few options"); when the human is stuck dictating, the agent asks "what questions do you have?" instead of guessing.

Markers live in chat, guards live in code, neither lands in committed prose. The point of both conventions is to externalise invisible state cheaply: which agent, what rules, whether it pushed back, and which lines are deliberately counter-intuitive (next: decision guards in §3).

2The ledger and the log: two files, two lifetimes v2.2

Why: a separate kanban file is a second source of truth that drifts. But collapsing everything into one file is the opposite failure: state buried in an archivable log gets archived, and open work disappears with it. So the split is by LIFETIME, not by topic. LOG.md is finished the moment an entry is written, so it archives. STATE.md lives until the work is done, so it never does.

# STATE.md  -- the ledger (edited in place, never archived)

| id     | status      | owner   | ask                          | gate            | evidence          |
| G1     | in-progress | @build  | Engine builds a dense radar  | G1.2            | -                 |
| G1.1   | done        | @build  | One database, two schemas    | shipped         | a1b2c3d PR #8     |
| G1.2   | in-progress | @build  | Recover typed discovery      | claim: feature/g1-2 @ 1410 | -      |
| G1.2.1 | done        | @build  | Port the seven channels      | shipped         | e4f5a6b, run 9f2e |
| G1.2.2 | open        | @build  | Bound the gather to 12       | G1.2.1          | -                 |
| G1.3   | blocked     | @design | Stage mechanism              | open Q: votes vs prior? touches scoring | - |

# LOG.md  -- the conversation (append-only, never edited, archivable)

### 2026-06-20-1410 - FROM: design - RE: G1.3 stage call - STATUS: open
Picking ONE stage mechanism. Leaning the prior-with-clamps path. @build, hold G1.3 children.
# this entry is OPEN, so G1.3 exists as a row above, in this same commit

The four-column board (Orca)

Orca shows each worktree with its agent's live state. The ledger's four statuses map one-to-one onto a four-column board, so the ledger and Orca read the same picture: a row's status is its column.

ColumnRow statusOrca worktree state
To doopenWorktree not yet created, or created and idle. The next unblocked row.
In progressin-progressAn agent is running in the worktree (Claude Code active). Carries the claim token.
Review / BlockedblockedAwaiting a human gate: a PR open for review, a permission prompt, or a blocking question. This is where the human looks first.
DonedoneMerged. The row cites its closing SHA and stays in the ledger; only the log archives.
One row, one worktree, one branch. A Task or Subgoal is the unit Orca isolates: fan it to its own worktree, let the Engineer work it, move its status across the four columns as the agent and the human act. The board is not a second file to maintain; it is the ledger, viewed through Orca's columns.

How the ledger stays one ledger across worktrees v2.2

Worktrees share one .git but each has its own working copy of STATE.md on its own branch. That second copy is the price of the separation that protects design work from a build-side checkout, and it has to be reconciled rather than assumed away. The convention that keeps the copies converged:

3Specs and decisions

Why: the failure mode is code shipping against a question that was still open, then paying for a reconciliation migration.

4Git, CI and deploy expanded

Why: deploys should be boring, attributable, and never depend on someone's laptop; CI should be a small set of composable jobs anyone can read.

The clean CI spine

Five composable jobs, each a single responsibility, wired so a project swaps the inside of a job without touching the shape. Agnostic by placeholder; one filled reference per stack ships alongside. The gates job runs ten scripts as of v2.6.

# .github/workflows/ci.yml  -- integration branch, every push
jobs:
  lint:      # format + lint, zero-warning budget
  typecheck: # static types across the workspace
  test:      # unit + integration; real DB for policy negatives
  gates:     # run every script in gates/ ; one job, many checks
  build:     # compile / package ; artifact, no deploy

# .github/workflows/deploy.yml  -- production branch only
on: { push: { branches: [release] } }
jobs:
  migrate:  # apply numbered migrations via CLI (never the web editor)
  web:      # deploy the app surface
  workers:  # deploy the compute surface

# .github/workflows/scheduled.yml  -- whitelisted QA + safety-net only
# a CI gate refuses new cron decorators outside this whitelist
A gate is worth more than the rule it replaces, and the ratio is measurable. v2.6 Before v2.6 this scaffold had 58 rules and 9 of them had any executable enforcement. The rest were prose, and prose was measured not to fire: one rule's own text recorded that all ten of its clauses were bound before the last three recurrences it existed to prevent, and another's headline detector recurred four times in the round that added it, missed by the author who wrote it. The finding that generalises: a detector phrased as a question gets answered from memory, a detector phrased as a command gets run. Three prose detectors that had recurred eleven times between them became spec-deliverable-check.py, spec-propagation-check.py and spec-citation-check.py. Expect a new gate to be wrong first: these three produced 165 findings on their first run against a real corpus and every one was false, which cost one whole check (deleted) and two exclusions. Run yours against your corpus before trusting it, because a gate people skim is worse than no gate.
Cleaner than the original spread. Replace a sprawl of one-off workflow files with three named workflows (ci, deploy, scheduled) plus a reusable composite action per stack. Long-running one-shots (backfills, re-resolves) are workflow_dispatch functions, not their own files. The rule: a reader should see the whole CI surface in three files.

5Schema and data discipline

Why: multi-tenant data integrity is won or lost in the migration layer, not the app layer.

The non-negotiable: every CREATE TABLE in a public schema ships ENABLE ROW LEVEL SECURITY plus at least one policy in the same migration. "Service-role-only via the backend" in a comment is not a constraint, the anon key reads it otherwise. A CI script enforces; the platform linter is the post-deploy backstop.

6Events and dispatch

Why: cron-and-poll architectures rot into invisible coupling; user trust dies the first time automation edits their data.

7LLM engineering

Why: LLM call sites multiply; without one gateway and hard output contracts, costs, providers and prompts sprawl untracked.

8Code quality and release

Why: style rules belong to machines; human review time is reserved for judgement.

9Security practice

Why: audits without a threat model produce hygiene findings and miss cross-tenant bugs.

10The agent setup: the four pillars

Why: this is the shell that makes AI-assisted development compound instead of reset every session. Four files-on-disk pillars, no hidden state.

PillarWhat it is
ConstitutionOne root instructions file both agents read every session: the operating model, the invariants, the surface layout. Kept tight; details pushed down to topic rules via file-pattern progressive disclosure ("editing workers/** loads pipeline-error-handling").
Ledger + logThe coordination pair (§2): an evidence-gated ledger (STATE.md, the only home of open/done, owner-closed) plus an append-only log (LOG.md, archivable by verbatim date-cut). No separate board. Goal-batches bundle related rows into one coherent pickup.
Rules & skillsTopic rule files loaded on demand by file-pattern, and reusable procedure skills the agents invoke. Three skills are mandatory at task entry and ship written-out in the scaffold: brainstorm before any new feature, plan before any code, verify before presenting. Sub-agent specialists are invoked at defined gates (spec promotion, new migrations, release scoping); delegation is the default when a task matches, isolated context, report back.
Memory + recoveryAn auto-memory index of durable facts and feedback ("how we work" corrections with why + how-to-apply), snapshotted into the repo so it survives environment resets, plus a from-zero restore playbook (target: under an hour) kept honest by the remote-only secrets rule.
Discipline is executable, not just documented. A doc an agent is supposed to honour gets skipped under context pressure; a hook always fires. The scaffold ships .claude/settings.json with two hooks: a session-start hook that surfaces the open ledger rows (enforces "read the ledger first"), and a pre-tool hook that blocks destructive shell commands (recursive delete, force-push, hard reset, destructive SQL, shared-env migration) and points the agent at the registry. Every rule that can be a hook or a gate is one; the rest live as loaded rules.
The cultural rules that matter most: the agent pushes back on the human's framing and critiques its own proposals (senior-engineer mode, not compliance mode); surfaces genuinely open decisions instead of presenting its lean as settled; reads sources literally end-to-end before binding anything; and treats "simplest validated path to ship" as the default against scope creep.

Retro: learning compounds into the rules v1.1

When a goal closes, after an incident, or on the human's call, each participant (Architect, Engineer, human) answers the same fixed question set independently, then the answers are laid side by side. The confluence, the agreements and the recurring frictions, is synthesised into proposed new ways of working, and each adopted item is promoted into a spec, a rule, or the operating model with a paired handoff entry and the human's bind. A retro that promotes no change was theatre. This is the memory-to-rules path on a cadence: a lesson that recurs and generalises stops being a per-session reminder and becomes a loaded rule.

11Skills: what we have, what we lack, how to stay agnostic gap analysis

Why: the scaffold is only as portable as its skills. A skill that names a product, a vendor, or a table is not reusable. This is the honest inventory.

Have, and already agnostic

Built for this scaffold (the gaps, now filled)

Reuse from the platform, do not re-author

From the market, patterns worth our own version

A scan of the public skills directories surfaces a few patterns this three-function-plus-Orca setup will want. Adopt the pattern, author our own product-neutral version rather than installing a third-party skill that names a vendor or a CI shape:

The agnostic test for any skill or rule: grep it for the product name, a vendor, or a table name. If a hit is load-bearing, it is not portable yet. Names go in placeholders ({{PRODUCT}}, {{DB_PLATFORM}}) or in the project's constitution, never in a reusable skill body.

12The scaffold layout what gets generated

The reusable template is one folder. Drop it into a new project, run the adoption checklist in ADOPT.md, fill the placeholders, delete what does not apply.

project-agent-scaffold/
  ADOPT.md                     # init checklist: fill placeholders, sequence (sect 13)
  CLAUDE.md                    # the constitution; auto-loaded by name in every Claude Code worktree
  ARCHITECTURE-PRINCIPLES.md   # Appendix A: invariants every PR holds
  DECISIONS.md                 # counter-intuitive deliberate choices, guarded inline by DEC-NN markers
  .gitignore
  .claude/
    settings.json             # hooks: executable discipline
    hooks/                     # session-start (surface open rows), guard-destructive (block)
    commands/                  # /check-handoff  /check-board  /ship
  operating-model/
    OPERATING-MODEL.md         # the functions, triggers, the ledger mechanics
    STATE.md                   # the ledger: only home of open/done, owner-closed, evidence-gated
    LOG.md                     # append-only conversation, carries zero state
    LOG-ARCHIVE.md             # verbatim date-cut moves out of LOG.md (never STATE)
    EXAMPLE.md                 # one scenario shown in both files, to copy the shape from
  specs/
    README.md                  # lifecycle + the six writing rules
    TEMPLATE.md                # spec template with the promotion checklist
    000-example-spec.md        # one worked, agnostic example
  rules/
    INDEX.md                   # the full rules library, one line each + file-pattern map
    *.md                       # 16 core rules in full (incl. 5 promoted from memory, + decision-guards); rest stubbed
  agents/
    ROSTER.md                  # the sub-agent roster + when-to-invoke gates
    *.md                       # 10 specialist reviewer definitions
  skills/
    SKILLS.md                  # mandatory set, full library, the gap analysis (sect 11)
    */SKILL.md                 # 9 skills incl. the 3 mandatory + the gap skills, all shipped
  ci/
    workflows/                 # ci.yml, deploy.yml, scheduled.yml (agnostic)
    gates/                     # 6 gate scripts: one folder, run as one CI job
    pull_request_template.md   # node link + verification checklist (copy to .github/)
    REFERENCE.md               # one filled stack reference (Node + Python + Postgres)
  memory/
    MEMORY.md                  # the durable-facts index template
    RECOVERY.md                # the from-zero restore playbook template

13Adoption order

Sequence, not schedule. Each step depends on the ones above it; there are no dates.

AAppendix · Architecture principles & build invariants

The constitution-level list, genericised in name.

BAppendix · The rules library

The topical rule files, loaded by file-pattern when an agent touches the matching surface. One line each; every one exists as a standalone doc. Core (shipped in full in the scaffold) is marked.

RuleOne-liner
rls-and-migrationsMigrations are the only schema truth; RLS + policy in the same migration as every CREATE TABLE; soft-delete suppression inside auth helpers; cross-store references are soft ids, never FKs.core
git-disciplineNo working-tree swap (checkout / reset / stash) while another agent may hold uncommitted shared state; commit the shared log promptly.core
ci-watch-and-fixWatch every push in-session; auto-fix two retries; architecture-class failures escalate with zero retries; nothing "shipped" until green.core
destructive-actions-registryEnumerated action classes (incl. a push to the production branch) need explicit human confirmation + an action-log line; three-tier shell-command safety.core
spec-discipline v2.6The whole spec surface in one file, merged from four: lifecycle (draft to binding, blueprint first when large or novel, blocking questions gate authoring); THE GATE (cross-model before every bind, the one non-optional clause, resting on 9-findings-self versus 22-including-5-blockers-independent); the learning loop (a findings corpus whose detector column is a COMMAND not a question, three of them now CI gates, stop on the first fix-induced defect); the six spec-writing rules; and doc-bug promotion. Replaced spec-lifecycle + spec-authoring-discipline + gate-findings-learning-loop + implementer-questions-are-doc-bugs.core
dispatch-and-eventsEvent-driven not cron; no auto-write to user-curated state; system actions default off; trigger-primitive named before any slice.core
llm-gatewayOne gateway by purpose; provider chains in registries; cache key includes provider and model; temperature-zero for stable judgments.core
threat-model + audit-promptNamed adversaries, boundaries, abuse cases; the audit reads the threat model first and names multi-tenant isolation explicitly.core
remote-only-executionNo local secret-dependent execution; one-shot jobs are remotely-invokable functions reading platform secret stores.core
production-commentsComments explain what and why-this-shape; no pointers to design docs; date stamps or SHAs for temporal grounding.core
loggingEverything leaves a queryable trail; autopsy-as-floor (failure reason persisted before death); families audit / run / health / external-call / observability; per-tenant, region-resident; no customer data in metrics.core
pipeline-error-handlingEvery stage validates inputs, catches errors, checks outputs; typed failure-mode catalogue; heartbeats + outcome markers; failures recorded to a queryable field, not just a log line.
scalability-throttlingNamed concurrency ceiling; semaphores, in-run batching, provider batch APIs; rate-limit events as a first-class metric family.core
web-app-error-disciplineEvery DB-client call destructures and logs before fallthrough; empty-state vs query-failure are visually distinct; explicit asset allowlists in matchers.
web-security-headersThe seven security headers + no framework fingerprint, declared in config and asserted by a CI script.core
shippable-contractSix day-one constraints on every UI component: tenancy, signed context, i18n, theme tokens, logical CSS, locale formatters.core
release-disciplineEvery new backend concept ships with a user-verifiable UI surface in the same release; admin fidelity fine, SQL-only verification not.
wireframe-port-auditThe port loop: build ports or creates in code, cleans up, ships an element-by-element audit diff in the same SHA, hands off; the Architect validates against the source and acks before the next node. 100 percent or it does not ship.core
design-tokens-single-sourceTokens live in one source both the wireframe and the code read; no look-alike values on either surface; divergence caught at the port audit.core
configuration-disclosureCustomer settings are presets + a few sliders; raw weights, thresholds and prompt text never reach the client bundle (CI-checked import boundary).
user-controlled-stateAutomation never writes user-curated tables; workers stage into *_candidate rows for explicit attach / reject.core
prompt-injection-defenceFive-layer pre-LLM scanner on all external content with clean / suspect / block, quarantine, pattern files, eval harness.core
observability-toolingThree tools, one job each: error tracking, uptime/status, a custom internal diagnostics surface over the pipeline's own health tables.
analytics-telemetryNo product analytics before launch; pipeline / audit / metric families are the instrumentation; region-resident tools; sub-processor list updates same-SHA.
design-language floor rulesA numbered list of non-negotiable visual rules for the product's signature surface, including typography and punctuation, enforced at design review.
dependency-policyLatest stable at scaffold time, exceptions documented with a bump ticket; prefer lib[extras] over hand-picked transitive deps.
integration-topology-firstEvery multi-service slice names the trigger primitive that wakes the next service before any code; platform-native primitives over custom polling.core
schema-evolutionChange a live table without downtime: expand, dual-write, backfill, contract. Never rename or retype in place.core
api-contract-versioningAdditive API changes free; breaking changes ship as a new version, never a mutation; deprecation has a window.core
queue-failure-handlingDead-letter queue, poison-message handling, bounded retry with backoff, back-pressure, visibility timeout sized to the work.core
planning-without-datesPlans, handoff entries and goal nodes carry no day counts, dates or Gantt timing. Order-of-dependency is the only ordering primitive.from memory
check-bindings-before-planningBefore filing a plan, spec or "open question", grep existing bindings on the same surface first; do not re-derive a settled decision or resurface a bound one as a fresh option.from memory
verify-not-self-reportA node flips to done on an independent verification (browser, integration test, diff, screenshot), never on the author's local-green alone. Structural acknowledgement is not functional acknowledgement.from memory
cost-comparison-honestyNever claim "X percent cheaper" by comparing a partition of an amortised fixed cost to a marginal cost; check whether the saving is marginal (the fixed cost actually leaves) or just shifted.from memory
no-stale-aggregate-seedDo not seed a per-entity field at creation time from a parent or sibling aggregate's attribute; it is a guess that goes stale. A spec-critic red flag before any spec binds.from memory
plugin-and-skill-adoptionCherry-pick community skills and plugins that fill a real gap; never install wholesale. Sweep upstream content (style, path defaults) before it lands. Skill installs are content copies, the design side's territory, not a destructive action.from memory
prose-and-copy-styleHouse writing conventions: no em-dash (use comma, period, parenthesis, hyphen), no inline emoji in document bodies, dark-theme-safe diagram defaults. Configurable per project; enforced at review.from memory
senior-engineer-modePush back on the human's framing, critique your own proposals, recommend the best option for the product even when it was not asked. Compliance mode is a defect.from memory
decision-guardsCounter-intuitive deliberate code gets a DEC-NN marker pointing at DECISIONS.md; the one allowed code-to-doc pointer; reserve for code that looks wrong but is not.core
doc-drift-on-shipA ship reconciles every doc the diff drifted (each side fixes the docs it owns, cross-boundary drift flagged in the handoff); docs-match-the-diff joins the verification checklist.core
retro-cadenceEvent-triggered retro; each participant answers a fixed set independently; the confluence is synthesised into new ways of working and promoted to a rule / spec / operating-model line.core
checkpoint-disciplineEngineer auto-commits WIP: checkpoints with a structured body (decisions / remaining / rejected approaches); resume reconstructs from them; squash before the PR; local by default.core
no-fake-data v1.3Scaffolds ship honest empty states, never fabricated demo data or controls for unbuilt stages; the live surface renders real data, the wireframe is the visual target only; a ported sample value is a port-audit deviation.core
platform-findings-backstop v1.4Consume each platform's native security + quality findings (code scanning, dependency + secret scanning, the host/DB linter, the cloud security advisor) as a standing backstop; triage every one, escalate trust-boundary criticals; complements the CI gates + security-reviewer, never replaces them. Name your own platforms, do not inherit a vendor.core
output-math-requires-binding v1.4Build never introduces or changes output-affecting math (ranking / scoring formulas + weights, calibration, thresholds, filters / floors, precedence) without a bound spec + human bind; propose, route to design, hand off.core
phase-aware-rigor-ladder v1.5Effort scales with phase (Tier 0 prototype / 1 MVP / 2 production); the security/CIA floor is constant at every tier; named promotion triggers (real data, money, multi-tenant, PII, 2nd contributor, public exposure) re-rate up a tier.core
epistemic-discipline v1.5Verify environment claims from a tool run this turn, never from stale memory; never invent flags / paths / APIs / columns; a third-party surface builds from the vendor's current docs and verifies by executing the artifact, verifiers exit non-zero; vendor guidance never overrides a bound spec; mechanize anything checkable in a script.core
eval-guards-a-lesson v1.5Every lesson bound from a real miss ships a checkable regression scenario that would have caught it, in the same change; a lesson without a guarding check is incomplete.core
secret-rotation-lifecycle v1.5Secrets rotate on a cadence and on exposure, zero-downtime via overlap; KEKs re-wrap on version bump; rotation is a gated action; code holds only a store reference.core
data-protection-as-code v1.5Privacy rights are code paths: export (DSAR), erasure that cascades across every store, retention enforced by a job, DPIA for new high-risk processing; personal data inventoried with lawful basis + residency.core
disaster-recovery v1.5Immutable, tested backups (3-2-1-1-0); sync is not a backup; PITR verified and restore drills prove named RTO/RPO per data class; provider-outage + bus-factor path written down.core
cicd-supply-chain-hardening v1.5CI is a trust boundary: least-privilege workflow permissions, SHA/digest-pinned actions and images, SBOM + provenance + signed releases, short-lived OIDC credentials, deploy gated behind the check suite.core
leakage-guard v1.5Keep portable surfaces free of secrets and environment-specific identifiers; specifics live in project config or an un-committed local profile; a two-tier CI grep denylist blocks a leak before it lands.core
deep-modules v1.6Depth over module count: a lot of behaviour behind a small interface; deletion test (does removing it concentrate or just move complexity); the interface is the test surface; one adapter is a hypothetical seam, two make it real; no speculative abstraction for a single implementation.core
resilience-engineering v1.7Degrade, do not die: timeouts on every remote call, circuit breaker, bulkhead, load-shed, designed degraded modes, kill-switch, bounded retry with backoff+jitter on transient+idempotent only. Extends queue-failure-handling to the in-request path.core
infra-hardening v1.7The running surface is least-privilege and pinned: non-root containers, digest-pinned scanned images, minimal runtime identity; IaC state remote+locked with plan-as-gate, federated short-lived deployer, no secrets in state.core
feature-flag-lifecycle v1.9A flag is born with a sunset (named removal trigger + owner in the same entry) and dies atomically (consumer + handler + UI + config removed together); a partial retirement leaves a control wired to nothing.core
output-grounding-verification v1.9Injection has no complete input fix, so verify the OUTPUT: every LLM claim over untrusted content traces to a verbatim quote that exists (deterministic) and entails (NLI) the claim; ungrounded output is rejected. The output-side companion to prompt-injection-defence.core
implementer-questions-are-doc-bugs v1.9When the build side must ask how bound mechanisms compose, or ships stricter or looser than bound, the answer promotes same-session into the owning spec as ONE stated flow; stricter-than-bound is a conformance bug too.core
dependency-update-cadence v2.1Dependabot PRs are triaged on a clock, never left to rot: security-flagged fast, minors batched on a fixed cadence, a staleness ceiling past which every PR carries a merge / hold-with-reason / close decision. A scheduled check surfaces the open queue on time; majors ride an equivalence gate (the transformers-HHEM battery is the reference); a hold-with-reason has a shelf life and a stale reason is itself a finding.core
handoff-log-state-split v2.2The handoff splits by LIFECYCLE: an append-only LOG (archivable only as a verbatim date-cut) and a STATE ledger, the sole home of open/done, where every item carries owner, gate, and an evidence field; done is unwritable without cited evidence. Ownership binds the write: only a row's owner mutates its status, a non-owner audit routes a claim instead of flipping, and anyone may create a row since the collision is in mutation, not creation. A CI gate blocks a log marker without a state item, an archive that touches state, a done without evidence, a copy missing a row the other tree has, and a status that differs from the other copy on a row this agent does not own.core
due-diligence-audit v1.9Recurring baseline-anchored audit: Mode A conformance-vs-bound-specs, Mode B twelve-heading scored due-diligence; literal code never claims; every audit re-verifies the prior Criticals first; scores ratchet against the pinned baseline; findings route as goal-per-heading; closures ship guards.core
traceability v2.3Autopsy-as-floor for every pipeline stage: each persists inputs / outputs / decisions including what it rejected and why, plus provenance, so any output walks back to its origin. Structured trace in the primary database; bulk bodies and model I/O in content-addressed object storage, deduplicated, never republished; tenant-isolated and residency-compliant; a trace-write failure degrades, never fails the run.core
web-sql-column-check v2.3Every hand-written SQL query in the web layer has its table and column references validated against the migration DDL in CI before merge; a reference the schema lacks fails the gate. Closes the wrong-column-in-raw-SQL class that typecheck, lint, build, and deploy all pass green. A static check against the DDL, no test database.core
observability-instrumentation v2.3Observable by construction: a mandatory declare-even-if-empty spec Observability slot (the design layer) plus a build / CI gate (declared-vs-emitted family reconcile, static label-cardinality lint, semantic-convention keys, refs-not-bodies). References the project's bound observability spec and never restates its measurement set.core
human-binds-never-operates v2.4The human is a designer and a binder, never a runtime operator. No running stage asks a person to label, rank, adjudicate, ack or decide a per-item outcome; a pipeline that needs one has a design defect, and the fix is to make the decision systemic. The one sanctioned human input to output-math is the design-time governance bind of a value that was DERIVED systemically. The boundary is the FIRST gate question, before any internal-correctness lens.core
framework-mirror-to-scaffold v2.3A change to how-we-engineer (a rule, agent, skill, the constitution, the spec template, a generic CI gate) mirrors same-session into the scaffold, generified; an unreachable scaffold is recorded as an owed mirror, not skipped; the mirror lands its INDEX, file-pattern, template, and handbook wiring, not just the file; a drift check runs at every retro and audit. The structural answer to the folder-only drift this changelog keeps catching.core

The eight rows marked "from memory" were promoted out of the source project's operating memory (the running list of how-we-work corrections) into standalone, product-neutral rules. This is the memory-to-rules path in action: a correction that recurs and generalises stops being a per-session reminder and becomes a loaded rule.

CAppendix · Skills & sub-agent roster

Skills are reusable procedure files; sub-agents are isolated specialist reviewers invoked at gates.

Skills, mandatory at task entry: brainstorming (before any new feature or architecture decision), writing-plans (before any code), verification-before-completion (before presenting any work).

Skills, the scaffold's own library: system-health v2.7 (the scan of the scaffold itself: enforcement ratio, orphan rules, growth-against-effect, family collisions, gate yield, dead gates; every step a command that prints a number, every admissible action a subtraction) · agent-deterministic-boundary · specs-pin-exact-contracts · goal-tree-planning · handoff-discipline · ci-gate-authoring · consolidate-parallel-work · planning-with-files · test-driven-development · codebase-audit-pre-push · systematic-debugging · create-pr · technical-change-tracker. Document and MCP skills are referenced from the host platform, not vendored.

Skills adopted from community, cherry-picked and adapted v1.7: improve-codebase-architecture (find shallow modules, deepen them, applies the deep-modules rule as a procedure) and grill-plan (stress-test a plan against existing bindings one question at a time, the narrowing counterpart to brainstorming). Both rewired to the scaffold's goal-tree / handoff, DECISIONS.md + decision-guards, and the Explore agent; bodies kept agnostic. Adapted from Matt Pocock's improve-codebase-architecture and grill-with-docs, per plugin-and-skill-adoption (cherry-pick, never install wholesale).

Sub-agents, engineering gates: system-architect (before any spec binds; topology + fault lines) · principal-engineer (18-month consequence, simpler-shape, incident pattern-match; every release-scope decision) · database-architect (every migration, policy edit, isolation question) · test-strategist (which layer tests what) · integration-test-designer (real-database security negatives, replay / idempotency) · security-reviewer v1.3 (the end-to-end boundary lens on any security-relevant surface, anchored on the threat model + SECURITY-HARDENING.md) · accessibility-reviewer (the accessibility floor on every customer surface) · incident-responder (mitigate, communicate, investigate; postmortem inside 48h) · spec-critic (the six spec-writing rules + dispatch questions) · design-critic (the visual floor rules) · prompt-engineer (designs and evals the per-purpose prompts) · adversarial-verifier v2.7 (takes ONE load-bearing claim, not an artifact, and tries to refute it; defaults to refuted when uncertain and returns survives rather than confirmed, because every other reviewer defaulting to accept reproduces the author's blind spot).

Sub-agents, research bench: a general research analyst plus optional domain specialists the design side delegates to. Default is to delegate when a task matches a specialist; isolated context, conclusions reported back.

Changelog

What changed in this operating system, newest first. The detail lives in the rules and the operating model; this is the index of what moved.

The Project Agent Scaffold · v3.0 · recreated as the agnostic blueprint for a reusable three-function operating system. Names are placeholders; the disciplines are the deliverable. No em-dash used, per house style. This HTML is the blueprint; the folder is generated from it. MIT licensed, see LICENSE. Provided as is, without warranty of any kind: use at your own discretion and risk. Author: Martin Molenkamp.