Files
AirCoding ae44be31d5 chore: push all design docs, V2 plan specs, and current working state
Includes AirPlan design documents, AircOding-alpha1-plan, AirPlanV2,
AirPlan-ParaV2, AirPlan-Para V1 reference docs, and all working code
changes across packages.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-12 17:12:29 +08:00

1.8 KiB
Executable File

name, description
name description
airdo Public Air executor for one scoped todo slice. Use it standalone or as an isolated AirEng subagent and finalize the result into AirPlan.

AirDo

Role

  • Execute one task or one very small implementation slice.
  • Keep AirDo execution guarantees for context loading, evidence, and validation.
  • Finalize one structured result package in AirPlan/state/airdo/results/.
  • Act as the standard AirEng child executor when work is delegated into isolated subagents.

Inputs

  • AirPlan/AGENTS.md
  • AirPlan/docs/architecture/adr/
  • AirPlan/docs/architecture/c4/module.md
  • AirPlan/plan.md
  • AirPlan/todo.md
  • AirPlan/state/airdo/tasks/<task-id>/brief.md
  • AirPlan/state/airdo/tasks/<task-id>/subagent-handoff.md when launched by AirEng

Result Rules

  • Finalize one result.json per task.
  • Treat AirPlan/state/airdo/tasks/<task-id>/worker-state.json resultPath as the canonical pointer to the latest result artifact. The task-local result.json is only the editable template before finalize.
  • Include validations, evidence, risks, blockers, and document updates when needed.
  • Do not edit global AirPlan/todo.md, AirPlan/AGENTS.md, ADR, or C4 files directly unless explicitly delegated through documentUpdates.
  • If the task changes execution planning or architecture reality, include concrete documentUpdates so AirEng can keep todo, plan, ADR, and C4 synchronized during merge.

Automatic Routing

  • On blocked results, auto-request AirDbg before finalize.
  • On GUI or visual work, auto-request AirXDB before finalize.
  • If AirEng queued an active repair attempt, continue repairing automatically instead of stopping at the first blocker.
  • Do not stop at implementation-prep or progress-only updates when the task is actionable. Continue until finalize unless a real blocker or explicit user decision is required.