aspis

Keep commits atomic — split a mixed change set into scoped, reviewable commits.

The one-time procedure to take an exported project to live — understand it, confirm the name/goal/stack with the user, run the deterministic `aspis bootstrap`, enrich the judgment files (AGENTS.md, ARCHITECTURE, context), verify, and let the package self-clean. Followed by the bootstrap agent.

Keep per-subsystem architectural intent current through the planning loop — read before designing, record an impact report on change, confirm with the user, apply a dated update, and verify the build against approved intent.

Audit a plan's task dependency graph for structural integrity — circular dependencies, missing prerequisites, orphan tasks, and dependency classification (hard/soft/warning). Produces a pass/warn/fail audit report per dependency so planners catch graph errors before build starts.

Every editing agent should start on a clean working tree so parallel work never collides.

Verify hooks ran, no secrets, protected paths untouched, and commit message valid before committing. Owned by the reviewer.

Prove the catalog regenerates the live runtime byte-for-byte; refuse export on any mismatch.

Plan and apply a catalog-to-runtime export, handling the six DecisionKind outcomes (ADD/UNCHANGED/UNKNOWN/UPDATE/PROTECT/CONFLICT).

Required fields and severity rubric (CRITICAL/HIGH/MEDIUM/LOW) for review findings, with file:line evidence convention. Owned by the reviewer.

Author a new git or runtime hook with a parity test to prove it behaves identically across both runtime surfaces (OpenCode/Claude).

Cross-reference `model_catalog.yaml` against live provider offerings via `aspis models --available`, surfacing STALE / MISSING / IN-USE-STALE model entries to keep model routing accurate.

Resolve the model tier for an agent via the 5-layer precedence chain (pin > per-agent > cap > project > global), then look up the canonical id in `model_catalog.yaml`.

Create, inherit, and merge ASPIS profiles (base.yaml + per-project overrides) — define which agents, runtimes, and settings are active for a project. Owned by system-lead.

Author one runtime-neutral catalog asset that is adapter-translated per runtime (OpenCode/Claude) — single source, no duplicate per-runtime files.

Cross-check a diff against the task packet's allowed/forbidden file lists; enforce R-001 scope boundaries with file:line evidence. Owned by the reviewer.

Apply the reviewer-owned architecture-constitution checks (from the system-of-record YAML) before issuing a review verdict.

Audit a PLAN against the architecture-constitution checks (system-of-record YAML) and emit a pass/fail report with file:line evidence.

Enforce cache-first discipline — check existing research before any new research; route to new research only on cache miss or staleness.

Validate the catalog's structural integrity — all references resolve, no broken links, schemas valid, no orphan assets.

Detect per-field per-agent catalog-to-live frontmatter drift and report with file:line evidence.

The R-008 human-gate workflow for rules, permissions, model-routing, and security posture changes — never an automated rewrite.

The 7-step R-008-gated path for bringing an external skill, source, or reference into the ASPIS catalog as a permanent asset.

Apply OWASP top 10 and core security checks (injection, authz, secrets, exposure) to a change before issuing a review verdict.

Detect interruption, classify the resumption type, and send a resume packet so the project-lead continues a session without losing context.

Pick the right builder tier (cheap/standard/deep) per packet version (V0–V4) and risk profile.

Codify "verify, don't trust" — what counts as valid evidence per review dimension, and how to judge it.

Infer the build mode from risk and scope, with auto-escalation and downgrade rules.

Validate a task packet on 4 dimensions (scope, feasibility, completeness, acceptance) scaled by V0–V4 maturity.

Translate a lead agent's return into project-aware language and decide the next action.

How the Project Lead keeps the project healthy, complete, and ready — detect when something is stuck, unhealthy, or missing; do the few simple things in its own remit (set the build mode); and route everything else to the System Lead or the right specialist. It detects and routes; it never fixes, builds, or changes the system itself.

How the System Lead safely changes project configuration — model routing, build mode, policy config, and stack — only through the aspis commands and the config data files, never by hand-editing a rendered runtime agent. Reachable user → project-lead → system-lead, or user → system-lead directly.

The Project Lead's project-intelligence skill — build a fast, accurate picture of the project (state, active feature, progress, changes, code locations, risks) by retrieving from deterministic sources on demand, never by loading the whole repo.

Run before creating or editing any file — confirm the repo is in a safe state to start (clean tree, right branch) with one deterministic command, and resolve or route any blocker before working. Keeps an agent from building on top of someone else's uncommitted changes or on the wrong branch.

Use at the start of any planning request to classify the work and size it — what kind of request this is, its complexity and risk, the right mode, and therefore how much planning it needs. Reads .aspis/config/modes.yaml so effort matches the work.

How much project context to load and in what order — the minimum for the task, level by level, stopping as soon as you can act. Hot context (what you almost always need) is read directly; deeper context is pulled on demand via tools; the deepest analysis is delegated to a helper. Used by every role that reads project context.

How to compose a commit message in the ASPIS convention — used by the committer before every commit.

Use to design the technical approach for a spec — the strategy, components, data flow, dependencies, and integration points, with the steps and gates that make it buildable. Produces the implementation plan, from the PLAN template, consistent with the project's existing architecture.

Use to write the specification for a feature — the goal, the problem, what is in and out of scope, the observable behavior, and measurable acceptance criteria. Produces the spec other agents build and test against, from the SPEC template.

Use to test implementation proportional to impact — from changed files to affected components to the relevant tests — instead of running the whole suite after every task. Records the test evidence later stages can reuse.

Use to break an approved plan into build-ready work — sequenced, dependency-ordered, appropriately sized task packets, each self-contained enough for an executor to implement, plus the execution, review, and testing strategy. Produces the TASKS list and per-task packets the Build Lead executes.