structure-auto

You are running structure in autonomous mode for the autopilot — no human to talk to. Produce the same artifact as /structure (docs/{task}/structure.md), in the same format, with every signature grounded in the actual code so a second agent can verify it.

Inputs (read first)

• docs/{task}/ prior artifacts (design.md required; facts.md, research.md if present).
• docs/objective.md (the human-owned frame) + the wiki (wiki/decisions/ = ratified authority; wiki/concepts/).
• .claude/skills/structure/SKILL.md defines the artifact format — match it exactly.

Autonomous decision procedure — ground-in-code + light panel

1. Ground every section in the ACTUAL code — Glob/Grep the real files, types, and patterns referenced by design.md. Never assume; verify against the tree. (Greenfield → ground in the conventions design.md sets.)
2. Populate structure.md (Code Shape / Data & Types / Interfaces / Change Ordering / Testing) with concrete signatures from reality.
3. Light panel — before finalizing the central contract (key types/interfaces), generate 2 alternative framings and pick the one that best fits existing patterns; record why in Technical Decisions.
4. Resolve Open Questions to recorded defaults where possible.

Consistency check (before the artifact is done)

Before declaring the structure complete, verify and fix: (internal) every referenced type/interface is defined, Change Ordering matches the dependency graph, each step is independently testable, no conflict with design.md; (against the codebase) Glob/Grep that every cited path/type/signature is real (no invented conventions). An inconsistency you can't resolve → docs/{task}/ESCALATE.md.

Guardrails (every mode)

• Ground in reality, never invent — every signature/type traces to actual code or a design decision; no invented conventions.
• Defaults, recorded — where /structure would ask the human, pick the best-supported default and record what/why/alternative in Technical Decisions.
• Escalate instead of guessing when it matters — if a choice would contradict a human-ratified wiki/decisions/ entry or change the objective frame → STOP and write docs/{task}/ESCALATE.md. Don't write a half-artifact.
• Self-contained, code-grounded output at docs/{task}/structure.md, matching the base skill's sections.

Architecture & design constraints (stewardship — read before deciding)

Before proposing structure or a design, CONSULT the captured, enforced system model:

• wiki/architecture/system-map.md — the module catalog, dependency graph, the 5 enforced invariants, and the key seams (the core domain entry point, the adapter Protocol, the data feed, the shared record seam). The [tool.importlinter] contracts in pyproject.toml ENFORCE this — uv run lint-imports fails the build on a boundary cross. Extend the existing seams; do NOT re-architect an enforced boundary. If a task genuinely needs a boundary to move, that is an ADR + a contract change (say so), never a silent cross.
• wiki/design-system/design-language.md (for any UI work) — the design tokens (theme.css), the component inventory, and the conventions (honest-n/a, the card/badge patterns, one-SPA tabs). Build UI in this language; do not invent ad-hoc styles or hardcode values that duplicate a token.

A design/structure that would violate a contract or the design language is wrong by construction.