refactor(sources): trim redundant rules, cleanup agent sources, harness-neutral orchestrate

- Drop rules/02-responses.md entirely: fully redundant with every harness's
  built-in system prompt (concise/no-preamble/no-emoji is baked in).
- Trim 04-tools.md's Parallelism and Context Management sections; trim
  05-verification.md's "run tests" bullet. All covered by harness defaults.
- Scope 01-session.md to claude only (memory/ hierarchy is Claude-specific).
- Update schemas/team.schema.json const-pin to match the new rules.order.
- Strip vestigial Claude-style YAML frontmatter from agents/*.md sources
  (extract_body was already discarding it; TEAM.yaml is the real source).
- Standardize plans/ path: drop \${PLANS_DIR} template var and use literal
  plans/ everywhere. Claude/codex/opencode now share one plans convention.
- Rewrite orchestrate skill team block and permission section to be
  harness-neutral: drop Claude model parentheticals and permissionMode /
  disallowedTools terminology.
- Rewrite architect agent's "no Bash execution" line generically to avoid
  naming Claude-specific tool identifiers in prose.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

skills/orchestrate/SKILL.md

@@ -10,17 +10,19 @@ You are now acting as orchestrator. Decompose, delegate, validate, deliver. Neve
 
 ```
 You (orchestrator)
-  ├── grunt         (haiku) — trivial, cheap implementer
-  ├── worker        (sonnet) — standard implementer
-  ├── senior        (opus) — ambiguous, architectural, or high-risk implementer
-  ├── debugger      (sonnet) — bug diagnosis and minimal fixes
-  ├── documenter    (sonnet) — documentation only, never touches source
-  ├── researcher    (sonnet) — one per topic, parallel fact-finding
-  ├── architect     (opus, effort: max) — triage, research coordination, architecture, wave decomposition
-  ├── reviewer      (sonnet) — code quality + AC verification + claim checking
-  └── auditor       (sonnet, background) — security analysis + runtime validation
+  ├── grunt       — trivial, cheap implementer
+  ├── worker      — standard implementer
+  ├── senior      — ambiguous, architectural, or high-risk implementer
+  ├── debugger    — bug diagnosis and minimal fixes
+  ├── documenter  — documentation only, never touches source
+  ├── researcher  — one per topic, parallel fact-finding
+  ├── architect   — triage, research coordination, architecture, wave decomposition
+  ├── reviewer    — code quality + AC verification + claim checking
+  └── auditor     — security analysis + runtime validation
 ```
 
+Models and effort levels are pinned per-agent in each harness's config. Pick agents by role; the harness handles model selection.
+
 ---
 
 ## Task tiers
@@ -201,9 +203,7 @@ When multiple risk tags are present, take the union. Spawn all required reviewer
 
 ### Permission model
 
-Agent `permissionMode` in frontmatter is overridden when the parent (you, the orchestrator) runs in `acceptEdits` or `bypassPermissions` mode — the child inherits the parent's mode. This means `permissionMode: plan` on read-only agents like architect, researcher, and reviewer is **not enforced at runtime**.
-
-The actual write protection for read-only agents comes from `disallowedTools: Write, Edit` — this is enforced regardless of permission mode. Do not rely on `permissionMode` as a safety boundary; rely on tool restrictions.
+Each agent declares its allowed tools in its frontmatter — read-only agents (architect, researcher, reviewer, auditor) cannot write, edit, or run shell commands because those tools are denied at the agent level, not gated by a runtime mode. Trust the per-agent tool restrictions as the real safety boundary. If a read-only agent needs to escalate to a write, route the work through an implementer instead of loosening permissions.
 
 ### Parallelism mandate