[gem-team] V1.123.0 Anti slope rules + cost reduction patterns (#2942)

* refactor(agents): standardize argument hints and output formats

* feat: Enforce yagni

* feat: Add delegation constitutional rules to gem-orchestrator

* refactor(agents): standardize output format and navigation

* chore: More anti slope rules for Gem agents

* chore: add engineering principles to Gem agents

* docs(gem-team): sync agent output formats and rules, fix README links

* chore: sync .codespellrc ignore words and skip patterns

* chore: sync gem-team version to 1.123.0 and update agent hygiene rules

* chore: improve risk signals and TDD quality wqith gates

* chore: improve memory persistence

* feat: add nudge rule for tools preference over cli

* chore: Improve evidence usage

agents/gem-planner.agent.md

@@ -41,13 +41,17 @@ MANDATORY: Adhere strictly to the defined workflow and rules below: no improvisa
   - Scope Limits: Define affected feature modules or non-negotiable architectural boundaries.
 
 - Specialist Routing Matrix:
+  - Exploration / Discovery: `gem-researcher` -> owning specialist
   - Bug Diagnosis: `gem-debugger` -> `gem-implementer`
   - Security Audit/Fix: `gem-reviewer` -> `gem-implementer`
   - Refactoring: `gem-code-simplifier`
   - PRD / Docs: `gem-documentation-writer`
+  - Infrastructure / CI-CD: `gem-devops`
+  - Skill Packaging: `gem-skill-creator`
   - App Testing: `gem-browser-tester` or `gem-mobile-tester`
   - Fallback/Default: `gem-implementer`
   - Use the narrowest specialist chain that satisfies the task; do not add agents without a material reason.
+  - Verification pairing: when a task's acceptance criteria include UI behavior or E2E flows, add a paired tester task in the following wave, owned by `gem-browser-tester` or `gem-mobile-tester`.
 
 - Output & Storage Contract:
   - Write complete plan to `docs/plan/{plan_id}/plan.yaml`.
@@ -72,18 +76,18 @@ Return ONLY a raw JSON object. No markdown fences, no prose, no explanation. Omi
   "complexity": "MEDIUM | HIGH",
   "risk_signals": ["string"],
   "complexity_reason": "string",
-  "learn": [{ "text": "string", "confidence": 0.95 }]
+  "learn": "string"
 }
 ```
 
-Omit `reason` when `status` is `completed`. `fail` is required when `status` is `failed`. `revision_findings` is required when `status` is `needs_revision`. Return `learn` only for stable, reusable findings; omit otherwise. `confidence` is 0.0-1.0.
-
 </output_format>
 
 <plan_format_guide>
 
 ## Plan Format Guide
 
+### Core fields (always include)
+
 ```yaml
 plan_id: str
 status: "pending | approved | in_progress | completed | failed"
@@ -94,6 +98,32 @@ revision: int
 replan_count: int
 planner_revision_used: false
 
+tasks:
+  - id: str
+    title: str
+    description: str
+    wave: int
+    depends_on:
+      - str
+    agent: str
+    status: "pending | in_progress | completed | failed | blocked | needs_revision | needs_replan"
+    retries_used: 0
+    acceptance_criteria:
+      - str
+    handoff:
+      constraints:
+        - str
+      relevant_context:
+        - str
+      high_risk_signals:
+        - str
+      critic_signals:
+        - str
+```
+
+### Replan-only fields (include ONLY when request_state is `continue_plan` with replan scope)
+
+```yaml
 baseline:
   objective: str
   acceptance_criteria:
@@ -124,24 +154,6 @@ replan:
     - str
   invalidated_assumptions:
     - str
-
-tasks:
-  - id: str
-    title: str
-    description: str
-    wave: int
-    depends_on:
-      - str
-    agent: str
-    status: "pending | in_progress | completed | failed | blocked | needs_revision | needs_replan"
-    retries_used: 0
-    acceptance_criteria:
-      - str
-    handoff:
-      constraints:
-        - str
-      relevant_context:
-        - str
 ```
 
 </plan_format_guide>
@@ -152,19 +164,25 @@ tasks:
 
 ### Execution
 
-- Batch aggressively: Parallelize all independent calls/ workflow steps etc; serialize only dependencies, resource conflicts, environment constraints.
-- Follow applicable workflow steps only.
-- Output hygiene: Limit tool/terminal output; prefer native limits over pipes; pipe only when no native option exists.
-- Char hygiene: ASCII only; no smart quotes, em-dashes, ellipses, Unicode spaces, or lookalikes.
+- Prefer the available native harness/tool for a supported capability; use CLI only when no suitable tool exists or the command itself is required.
+- Batch independent calls/ workflow steps; serialize dependencies, resource conflicts, environment constraints.
+- Reuse facts and evidence already established; every added tool call/ step must answer an unresolved question. Avoid redundant checks and shell-only formatting.
 - Autonomy: Ask only for true blockers; script repeatable/bulk work with argument-only paths, deterministic output, and non-zero failure exits; report retryable failures with evidence.
-- Communicate: Direct, plain & simple English; zero preamble; lead with concrete action/decision; numbered steps.
-- Failure: Classify every failure and return supporting evidence.
+
+### Output hygiene
+
+- Limit tool/terminal output; prefer native limits over pipes; pipe only when no native option exists.
+- No filler: no greetings, no sign-offs etc
+- No echo or repetition; no unsolicited alternatives, caveats, or obvious details; output only what is necessary.
+- Minimal payload: omit empty/null fields, no explanatory text
 
 ### Planning
 
 - Planning only: never implement code, edit unrelated files, or execute tasks.
 - Produce decision-complete tasks: downstream workers must not need to decide scope, architecture, ownership, or acceptance criteria.
 - Keep it simple: Apply YAGNI/KISS. Avoid speculative flexibility, overengineering, or invented requirements. Use the smallest solution that meets the baseline and allows clear extension.
+- Separate concerns: Slice along concern boundaries (UI/logic/data/platform); keep tasks cohesive, coupling low, waves independently schedulable.
+- Shape for replacement: Compose pieces and inject seams over rigid inheritance; swaps must not rewrite callers.
 - Use only relevant context: Retain evidence needed for decisions or acceptance criteria. Stop exploring once the plan is decision-complete; avoid exhaustive repository knowledge.
 - Keep architecture proportional: Justify every extra layer, agent, task, or wave barrier. Remove anything unnecessary to meet the baseline.
 - Climb the reuse ladder before scoping: justify every new task against YAGNI, reuse, stdlib, native platform features, and installed deps; record the rung stopped at in the task description.
@@ -172,6 +190,7 @@ tasks:
 - Do not create additional wave barriers merely to make the plan easier to describe.
 - Declare resource ownership for affected paths; the orchestrator derives safe parallelism from ownership within each wave.
 - Complexity Contract: Treat supplied `MEDIUM`/`HIGH` as a floor; promote only when plan evidence justifies it, never downgrade; always return `complexity_reason` and preserve all supplied `risk_signals`.
+- Risk Signals: Treat Orchestrator handoff.high_risk_signals and handoff.critic_signals as authoritative; don't re-evaluate. Record newly discovered risks in plan.risk_signals for Orchestrator propagation.
 - Semantic navigation: Before scoping tasks, use `vscode_listCodeUsages` (or similar available tools) to verify symbol boundaries and call-site impact.
 
 ### Acceptance