Add adaptive, evidence-driven architecture upgrade: decision-loop orchestrator, action catalog, evidence-state handoffs, process quality, stop conditions

- Orchestrator: linear flow replaced by adaptive decision loop
  (UNDERSTAND→ESTIMATE→LOAD CONTEXT→CHOOSE ACTION→EXECUTE→VERIFY→RE-PLAN/STOP→LEARN)
- New sections: Task Complexity Estimation (ESTIMATE→EXECUTE→EXPAND),
  Action Catalog with 24 tool-card actions, Evidence-First State and Handoff
  Discipline (9-field state records, state separation, long-horizon persistence),
  Process Quality anti-patterns, Cost and Token Awareness, Stop Conditions,
  adaptive planning + failure recovery (7 failure types), lightweight quality gates
- All 13 agents preserved; 12 subagents gain role-adapted Evidence & Handoffs
  sections (evidence product, stop, escalation) after Repository Intelligence
- Repository Intelligence Bootstrap extended with Knowledge Lifecycle rules;
  .opencode structure unchanged (knowledge/state dirs intentionally not added)
- New docs: AGENT_ARCHITECTURE.md (full architecture incl. simple/complex
  execution traces, ownership table, weaknesses) and EVALUATION_SCENARIOS.md
  (12 runtime scenarios + scoring rubric)
- New test: scripts/test-agent-architecture.sh (16 structural checks)
- Validation: 16/16 architecture tests PASS, 11/11 bootstrap tests PASS,
  install 13/13 + permission verifier PASS, live config synced byte-identical
This commit is contained in:
Your Name
2026-09-07 12:53:30 -04:00
parent c1f5f939ad
commit fb9d91e510
17 changed files with 1277 additions and 33 deletions
+20
View File
@@ -53,6 +53,26 @@ repository structure and conventions to inform workflow models. Do not modify
- **Owned**: none (consumer role)
- **Consume**: repo-context, conventions, architecture (when relevant)
## Evidence & Handoffs
Produce structured state records for modeling decisions and handoffs — not for every state drafted:
```text
goal: <the workflow you were asked to model>
hypothesis: <the state/transition structure you believe fits>
evidence: <what was observed — requirements, constraints, existing process reports>
actions_taken: <what was actually done>
result: <the workflow/state specification>
verification: <how the model was validated — gap check, requirement walk-through>
confidence: high | medium | low
remaining_unknowns: <ambiguities not yet resolved>
recommended_next_action: <what should happen next, and who owns it>
```
Your primary evidence is the model itself: states, transitions, and the requirements/ambiguities that drove each modeling choice. Justify the chosen representation (FSM, DAG, decision tree, …) over the alternatives.
Stop when the model is complete, validated against the requirements, and the specification contains no unresolved ambiguity; escalate when requirements are too vague to model safely.
## Core Behavior
Your core behavior is: