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>

AirPlan/docs/spec/AirPlan-ParaV2/plugins/airdo/commands/airdo.md

@@ -0,0 +1,38 @@
+---
+description: Start, inspect, hand off, or finish one scoped AirDo task slice with automatic AirXDB/AirDbg routing and AirPlan result finalization
+argument-hint: [enter|status|handoff|finish]
+allowed-tools: [Read, Glob, Grep, Bash, Write, Edit]
+---
+
+# /airdo
+
+Use AirDo for one narrow execution slice. It can run directly in the parent thread, but it is primarily designed to be launched as an isolated AirEng subagent.
+
+## Steps
+
+1. Parse `$ARGUMENTS`; default to `status` when empty.
+2. Always operate from the current project root and store worker state under `AirPlan/state/airdo/`.
+3. Run the matching mode:
+
+```bash
+python "$HOME/plugins/airdo/scripts/airdo_mode.py" --mode <enter|status|handoff|finish> --project . --task-id <task-id>
+```
+
+4. For `enter` or `handoff`, load:
+   - `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`
+
+5. When AirDo is invoked as an AirEng child:
+   - Treat the session as isolated and rebuild context only from the files above.
+   - Stay inside the task write scope from the brief/handoff.
+   - Finalize exactly one structured result under `AirPlan/state/airdo/results/<task-id>.json`.
+   - Treat `AirPlan/state/airdo/tasks/<task-id>/worker-state.json` `resultPath` as the canonical pointer to the latest result artifact. Do not assume the task-local template `result.json` is the finalized output.
+   - Do not stop at "准备实施", implementation-plan-only, or generic progress replies when the task is actionable. Continue editing, validating, and finalizing unless a real blocker or user decision is required.
+   - When the task changes planning or architecture reality, include concrete `documentUpdates` for `AirPlan/plan.md`, `AirPlan/docs/architecture/adr/`, and `AirPlan/docs/architecture/c4/module.md` instead of leaving those docs stale.
+
+6. On GUI-like work, route acceptance through AirXDB before finishing.
+7. On blockers or failed validation, route through AirDbg, continue through active repair briefs when present, and return one structured result for AirEng to merge.