docs(framework): add agency & persistence patterns to config + guides
Some checks failed
ci/woodpecker/push/ci Pipeline failed
ci/woodpecker/pr/ci Pipeline failed

Seven additive behavioral rules distilled from the Claude Code system
prompt, competitor autonomous-agent prompts (Devin/Cline/Cursor/Windsurf/
Droid/Manus/Replit), and Fable 5 consumer-prompt deltas:

- SOUL.md: own-mistakes stance, USER.md formatting override, reversibility
  heuristic (hard-gate-reconciled), injected-content caution
- AGENTS.md: Block vs. Done semantics
- E2E-DELIVERY.md: failure-handling retry budget, pre-done self-interrogation
- ORCHESTRATOR.md: worker-prompt-quality standard, trust-but-verify
- QA-TESTING.md: integrity guardrails

Additive only (+37/-0). Independent review passed (one remediation applied).

Refs #542

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-15 23:09:47 -05:00
parent c461380a4a
commit d481a74a86
5 changed files with 37 additions and 0 deletions

View File

@@ -595,6 +595,15 @@ Review: needs-qa (1 blocker, 2 high) → QA task {task_id}-QA created
---
## Worker Prompt Quality (Hard Rule)
Brief each worker as if it just walked in with zero prior context — terse prompts produce shallow, generic work.
1. State the goal, the constraints, and what has already been ruled out.
2. Include concrete `file:line` references and the exact expected output/return form.
3. Never delegate understanding: the orchestrator owns synthesis. Do not pass "based on your findings, decide what to do" — give the worker a bounded, well-specified task.
4. When tasks are independent, dispatch workers in parallel; reserve sequential dispatch for genuine dependencies.
## Worker Prompt Template
Construct this from the task row and pass to worker via Task tool:
@@ -653,6 +662,8 @@ End your response with this JSON block:
`status=success` means "code pushed and ready for orchestrator integration gates";
it does NOT mean PR merged/CI green/issue closed.
**Trust but verify (Hard Rule):** A worker's reported `status` describes what it intended, not necessarily what landed. Before accepting `status=success`, the orchestrator MUST confirm the outcome independently — verify the commit SHA exists on the branch, the expected files changed, and quality gates/tests actually ran green. Never relay a worker self-report as completion evidence.
## Post-Coding Review
After you complete and push your changes, the orchestrator will independently