[gem-team] V1.121.0 Anti slope rules

.github/plugin/marketplace.json

@@ -848,7 +848,7 @@
       "name": "gem-team",
       "source": "plugins/gem-team",
       "description": "Self-Learning Multi-agent orchestration framework for spec-driven development and automated verification. With smarter tool calling and leaner context.",
-      "version": "1.119.0"
+      "version": "1.121.0"
     },
     {
       "name": "gesture-review",

agents/gem-browser-tester.agent.md

@@ -85,4 +85,12 @@ Omit `reason` when `status` is `completed`. When `status` is `failed`, `fail` is
 - Store screenshots, traces, logs, and DOM snapshots in `docs/plan/{plan_id}/evidence/` only if required.
 - Semantic navigation: Prefer `vscode_listCodeUsages` and `vscode_renameSymbol` (or similar available tools) over grep for symbol resolution and call-site enumeration.
 
+## UI Checks
+
+- Verify every interactive element has a real behavior or state toggle.
+- Verify every data-displaying UI has empty, loading, and error states.
+- Inspect mobile viewports for horizontal overflow, text escaping, and broken layouts.
+- Verify all interactive elements are keyboard-accessible with visible focus indicators.
+- Verify all text meets WCAG AA contrast standards.
+
 </rules>

agents/gem-code-simplifier.agent.md

@@ -86,4 +86,10 @@ Omit `reason` when `status` is `completed`. When `status` is `failed`, `fail` is
 - Rename/remove exports, components, API handlers, database schemas, config keys, routes, or events only with explicit permission or proof of privacy.
 - Semantic navigation: For renames, use `vscode_renameSymbol` for atomic updates. Use `vscode_listCodeUsages` (or similar available tools) to verify blast radius before removing dead code.
 
+## Quality Directives
+
+- Every refactoring must have a one-line reason.
+- No buzzwords ("Revolutionary", "Seamless", etc.).
+- Remove AI-slop comments: decorative separators, restating-the-obvious, workflow narration, empty labels, vague TODOs. Keep comments explaining business logic, intent, or security.
+
 </rules>

agents/gem-documentation-writer.agent.md

@@ -64,4 +64,10 @@ Omit `reason` when `status` is `completed`. When `status` is `failed`, `fail` is
 - Treat source code as read-only truth; document exactly the actual stack.
 - Semantic navigation: Use `vscode_listCodeUsages` (or similar available tools) to verify API surface before documenting.
 
+## Quality Directives
+
+- No buzzwords ("AI Powered", "Revolutionary", "Seamless", etc.). Use specific language.
+- Every section must exist because the product needs it. Remove template filler.
+- No fabricated statistics or claims. Use `[REAL DATA]` or omit the claim.
+
 </rules>

agents/gem-implementer.agent.md

@@ -76,8 +76,12 @@
 - Gated writes: After each edit, call `get_errors` to validate syntax. If errors are introduced, revert and retry.
 - Fix root causes: Grep call sites. Patch shared functions instead of caller-level hacks.
 - Minimal footprint: Shortest working diff wins. Prefer deletion over addition; no unrequested abstractions, extra deps, or boilerplate.
-- Defensive design: Trust no input, validate boundaries, plan errors first, and match state management to complexity.
+- Defensive + fail-fast: Trust no input; validate boundaries; plan errors first; match state mgmt to complexity. Throw on invalid input or impossible state; never swallow into silent wrong output. Anticipate failing states, not imaginary futures (YAGNI).
 - Strict compliance: Meet all `acceptance_criteria` while keeping code simple, dry, and functional (KISS/DRY/FP).
+- SOLID: One job per unit (SRP); open for extension, closed for change (OCP); narrow roles (DIP/ISP); substitutes must not shift behaviour (LSP); compose over inherit; no reach-through chains (LoD).
+- Concern integrity: Respect the plan's slices (UI/logic/data/platform); keep units cohesive, siblings loosely coupled, pieces swappable.
+- Least surprise: Name and shape functions to behave predictably; expose intent, hide detail.
+- Boy Scout tidies go to `gem-code-simplifier` or a dedicated pass, never inside a TDD cycle.
 - Verify non-trivial changes: Leave one runnable assert or small test behind for logic not covered by TDD. Skip only for trivial one-liners.
 - Label trade-offs: Tag intentional hacks.
 - Challenge requirements: Clarify ambiguous specs. If two solutions are equal size, choose the algorithmically robust option.
@@ -95,4 +99,10 @@
 - Testing: Test both iOS and Android unless the acceptance criteria explicitly limit behavior to one platform. Record the other platform as not applicable with a reason.
 - Architecture: Validate boundary inputs, pre-plan error handling, and match sync/async patterns.
 
+## Quality Directives
+
+- Every interactive element must have a real behavior or a visible `// TODO` + "Coming soon" label. No dead buttons.
+- Build features in source. Do not use external scripts to patch source or CSS.
+- Every major decision must have a one-line reason.
+
 </rules>

agents/gem-mobile-tester.agent.md

@@ -84,4 +84,12 @@ Omit `reason` when `status` is `completed`. When `status` is `failed`, `fail` is
 - Use required device farms; never substitute simulator-only testing.
 - Semantic navigation: Prefer `vscode_listCodeUsages` and `vscode_renameSymbol` (or similar available tools) over grep for symbol resolution and call-site enumeration.
 
+## UI Checks
+
+- Inspect device sizes, orientations, and text scales for horizontal overflow, clipped content, and broken layouts.
+- Verify every interactive element has a real behavior or state toggle.
+- Verify every data-displaying UI has empty, loading, and error states.
+- Verify all interactive elements are keyboard-accessible with visible focus indicators.
+- Run/build the app and exercise every interactive element before declaring done.
+
 </rules>

agents/gem-orchestrator.agent.md

@@ -35,13 +35,14 @@ MANDATORY: `Phase 0` is your non-delegable entry point for every single interact
   - `research`: `research_question` and `expected_deliverable`.
   - `execute`: `objective`, `acceptance_criteria`, and `constraints`.
   - `debug`: `failure`, `expected_behavior`, and available `evidence`.
+- Intent priority: When multiple intents match, resolve by priority: `challenge` > `debug` > `research` > `execute` > `discuss`. The lowest-priority matching intent wins only when no higher-priority intent is clearly supported by the request's verbs, objects, and expected outcome.
 - Read only relevant memory to request.
 - Define and evaluate risk signals once for reuse by all later phases:
   - `high_risk_signals`: `architecture`, `contract_change`, `breaking_change`, `api_change`,
     `schema_change`, `auth_change`, `data_flow_change`, `migration`, `security_sensitive`,
     `irreversible`, `shared_state`, `cross_domain_impact`.
   - `critic_signals`: `architecture`, `breaking_change`, `cross_domain_impact`.
-  - Match only risks that the requested change explicitly or strongly implies it may alter. A term mentioned as subject matter is not by itself a match.
+  - Match only risks that the requested _change_ explicitly or strongly implies it may alter. A term mentioned as subject matter or context is not by itself a match. Evaluate against what will be modified, not what the task is about.
 - Assign provisional complexity from supplied evidence only; never explore to improve confidence:
   - `HIGH`: Any `high_risk_signals` match.
   - `MEDIUM`: Multiple dependent tasks, files, components, or agents without a high-risk signal.
@@ -64,22 +65,37 @@ MANDATORY: `Phase 0` is your non-delegable entry point for every single interact
 
 #### Fast path: direct specialist execution
 
-For a single bounded task with clear acceptance criteria, one owner, and no high-risk signal:
+Eligibility requires all of:
+
+- Single owner: One narrowest specialist can complete the task end-to-end.
+- Bounded scope: The change is contained to one domain or file area.
+- Clear acceptance criteria: Explicitly supplied, or trivially inferable (e.g., "fix the typo" -> typo is corrected). If criteria require investigation to define, route to `gem-planner` first to define criteria, then fast-path execution.
+- No high-risk signal: No `high_risk_signals` match against the proposed change.
+
+When eligible:
 
 - Use the assigned or generated `plan_id` for correlation only.
 - Do not create a persistent plan.
 - Do not invoke `gem-planner` or `gem-reviewer`.
 - Delegate directly to the narrowest specialist.
 - Require only relevant verification evidence.
 
-Promote to a persistent plan if delegation reveals dependencies, shared state, contract/risk changes, or durable-evidence needs. Keep `plan_id`, create `docs/plan/{plan_id}/plan.yaml`, preserve valid context/evidence, and route remaining work through `gem-planner`. Never redo non-stale completed work:
+#### Promotion: ephemeral to persistent plan
+
+`"Single owner"` means the initial specialist dispatch, not necessarily the final owner. Promotion during execution is expected, not exceptional. Promote when delegation reveals any of:
+
+- Multi-specialist dependency
+- Shared mutable state or cross-domain impact
+- Contract or API change
+- Durable evidence needs beyond a single specialist's scope
+
+On promotion:
 
-- preserve current state
-- preserve the current task owner; route only newly discovered scope to additional specialists
-- preserve the original task's current wave
-- keep completed work in its existing position and place dependent new tasks in later waves
-- create persistent plan
-- route remaining scope to planner
+- Keep `plan_id`, create `docs/plan/{plan_id}/plan.yaml`, preserve valid context/evidence.
+- Preserve current state and the current task owner; route only newly discovered scope to additional specialists.
+- Preserve the original task's current wave; completed work stays in place, dependent new tasks go in later waves.
+- Route remaining scope to `gem-planner`.
+- Never redo non-stale completed work.
 
 ### Phase 2: Planning
 

agents/gem-planner.agent.md

@@ -165,6 +165,8 @@ tasks:
 - 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.

agents/gem-reviewer.agent.md

@@ -116,4 +116,11 @@ Omit `reason` when `status` is `completed`. `fail` is required when `status` is
 - For `code`/`integration` targets, run an over-engineering pass: flag unrequested abstractions, avoidable new dependencies, boilerplate, diffs that could be shorter or more correct, and deliberate simplifications. Report each as a warning with the leaner alternative.
 - Semantic navigation: Use `vscode_listCodeUsages` (or similar available tools) to verify blast radius of changed symbols — all callers, holders, and tests.
 
+## Quality Checks
+
+- Verify every decision has a reason beyond "it's the default."
+- Require a one-line reason for all major decisions.
+- Flag any interactive element without a real behavior or visible `// TODO` as a blocking issue.
+- Flag any use of external scripts to patch source or CSS as a blocking issue.
+
 </rules>