@fro.bot/systematic 2.9.0 → 2.9.2

package/README.md

@@ -305,7 +305,7 @@ Configuration is loaded from multiple locations and merged (later sources overri
   },
   "agents": {
     "security-sentinel": {
-      "model": "anthropic/claude-sonnet-4-5"
+      "variant": "thinking"
     },
     "workflow/systematic-implementer": {
       "steps": 20
@@ -326,11 +326,11 @@ Configuration is loaded from multiple locations and merged (later sources overri
 | `bootstrap.enabled` | `boolean` | `true` | Inject the `using-systematic` guide into system prompts |
 | `bootstrap.file` | `string` | — | Custom bootstrap file path (overrides default) |
 
-Agent overlays support `model`, `variant`, `temperature`, `top_p`, `permission`, `mode`, `color`, `steps`, `hidden`, exact-agent-only `disable`, and managed `skills`. `skills` uses bundled skill frontmatter names like `ce:review`; it is a shortcut that writes OpenCode `permission.skill` rules, not a native OpenCode agent field. Because `permission` and `skills` control tool access, they are only accepted from user config or `$OPENCODE_CONFIG_DIR/systematic.json`; project config may tune behavior but cannot loosen a user's permission policy.
+Agent overlays support `model`, `variant`, `temperature`, `top_p`, `permission`, `mode`, `color`, `steps`, `hidden`, exact-agent-only `disable`, and managed `skills`. `color` accepts `#RGB`, `#RRGGBB`, or OpenCode named color tokens matching `[a-zA-Z][a-zA-Z0-9-]*`; whitespace/freeform numeric strings are rejected. `skills` uses bundled skill frontmatter names like `ce:review`; it is a shortcut that writes OpenCode `permission.skill` rules, not a native OpenCode agent field. Because `model` controls provider routing/cost/privacy and `permission`/`skills` control tool access, those fields are only accepted from user config or `$OPENCODE_CONFIG_DIR/systematic.json`. Project config may tune non-sensitive presentation and runtime fields such as `variant`, `temperature`, `top_p`, `mode`, `color`, `steps`, `hidden`, or exact-agent `disable`, but it cannot choose model/provider routing or loosen permission/capability policy.
 
-Systematic separates config-source precedence from overlay precedence. Config files merge in this order: user config, project config, then `$OPENCODE_CONFIG_DIR/systematic.json` if set. Higher-priority `agents.<key>` and `categories.<id>` entries replace lower-priority entries wholesale, while unrelated keys survive. Project overlays are the exception for security fields: same-key project overlays preserve user-level `permission` and `skills` fields instead of erasing them. After the effective config is built, exact `agents` overlays beat category overlays, which beat built-in policy defaults, bundled markdown defaults, and OpenCode inherited defaults.
+Systematic separates config-source precedence from overlay precedence. Config files merge in this order: user config, project config, then `$OPENCODE_CONFIG_DIR/systematic.json` if set. Higher-priority `agents.<key>` and `categories.<id>` entries replace lower-priority entries wholesale, while unrelated keys survive. Project overlays are the exception for trust-sensitive fields: same-key project overlays preserve user-level `model`, `permission`, and `skills` fields instead of erasing them. After the effective config is built, exact `agents` overlays beat category overlays, which beat built-in policy defaults, bundled markdown defaults, and OpenCode inherited defaults.
 
-Bundled agents omit `model` by default so OpenCode model inheritance keeps working. Systematic emits a `model` only when you configure one explicitly; provider-specific zero-config model defaults are intentionally deferred.
+Bundled agents omit `model` by default so OpenCode model inheritance keeps working. Systematic emits a `model` only when you configure one explicitly in user or custom config; provider-specific zero-config model defaults are intentionally deferred.
 
 Native OpenCode agents with the same emitted key are full replacements. An exact Systematic overlay for that key conflicts, while category overlays skip native replacements and continue applying to other bundled agents. Use one canonical agent key form across config sources (`security-sentinel` or `review/security-sentinel`) because alias collisions fail duplicate-target validation.
 

package/agents/design/design-iterator.md

@@ -1,7 +1,7 @@
 ---
 name: design-iterator
 description: "Iteratively refines UI design through N screenshot-analyze-improve cycles. Use PROACTIVELY when design changes aren't coming together after 1-2 attempts, or when user requests iterative refinement."
-color: violet
+color: accent
 ---
 
 You are an expert UI/UX design iterator specializing in systematic, progressive refinement of web components. Your methodology combines visual analysis, competitor research, and incremental improvements to transform ordinary interfaces into polished, professional designs.

package/agents/design/figma-design-sync.md

@@ -1,7 +1,7 @@
 ---
 name: figma-design-sync
 description: "Detects and fixes visual differences between a web implementation and its Figma design. Use iteratively when syncing implementation to match Figma specs."
-color: purple
+color: accent
 ---
 
 You are an expert design-to-code synchronization specialist with deep expertise in visual design systems, web development, CSS/Tailwind styling, and automated quality assurance. Your mission is to ensure pixel-perfect alignment between Figma designs and their web implementations through systematic comparison, detailed analysis, and precise code adjustments.

package/agents/docs/ankane-readme-writer.md

@@ -1,7 +1,7 @@
 ---
 name: ankane-readme-writer
 description: "Creates or updates README files following Ankane-style template for Ruby gems. Use when writing gem documentation with imperative voice, concise prose, and standard section ordering."
-color: cyan
+color: info
 ---
 
 You are an expert Ruby gem documentation writer specializing in the Ankane-style README format. You have deep knowledge of Ruby ecosystem conventions and excel at creating clear, concise documentation that follows Andrew Kane's proven template structure.

package/agents/review/adversarial-reviewer.md

@@ -2,7 +2,7 @@
 name: adversarial-reviewer
 description: Conditional code-review persona, selected when the diff is large (>=50 changed lines) or touches high-risk domains like auth, payments, data mutations, or external APIs. Actively constructs failure scenarios to break the implementation rather than checking against known patterns.
 tools: Read, Grep, Glob, Bash
-color: red
+color: error
 
 ---
 

package/agents/review/agent-native-reviewer.md

@@ -1,7 +1,7 @@
 ---
 name: agent-native-reviewer
 description: "Reviews code to ensure agent-native parity -- any action a user can take, an agent can also take. Use after adding UI features, agent tools, or system prompts."
-color: cyan
+color: info
 tools: Read, Grep, Glob, Bash
 ---
 

package/agents/review/api-contract-reviewer.md

@@ -2,7 +2,7 @@
 name: api-contract-reviewer
 description: Conditional code-review persona, selected when the diff touches API routes, request/response types, serialization, versioning, or exported type signatures. Reviews code for breaking contract changes.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/cli-agent-readiness-reviewer.md

@@ -2,7 +2,7 @@
 name: cli-agent-readiness-reviewer
 description: "Reviews CLI source code, plans, or specs for AI agent readiness using a severity-based rubric focused on whether a CLI is merely usable by agents or genuinely optimized for them."
 tools: Read, Grep, Glob, Bash
-color: yellow
+color: warning
 ---
 
 # CLI Agent-Readiness Reviewer

package/agents/review/cli-readiness-reviewer.md

@@ -2,7 +2,7 @@
 name: cli-readiness-reviewer
 description: "Conditional code-review persona, selected when the diff touches CLI command definitions, argument parsing, or command handler implementations. Reviews CLI code for agent readiness -- how well the CLI serves autonomous agents, not just human users."
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 ---
 
 # CLI Agent-Readiness Reviewer

package/agents/review/correctness-reviewer.md

@@ -2,7 +2,7 @@
 name: correctness-reviewer
 description: Always-on code-review persona. Reviews code for logic errors, edge cases, state management bugs, error propagation failures, and intent-vs-implementation mismatches.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/data-migrations-reviewer.md

@@ -2,7 +2,7 @@
 name: data-migrations-reviewer
 description: Conditional code-review persona, selected when the diff touches migration files, schema changes, data transformations, or backfill scripts. Reviews code for data integrity and migration safety.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/dhh-rails-reviewer.md

@@ -2,7 +2,7 @@
 name: dhh-rails-reviewer
 description: Conditional code-review persona, selected when Rails diffs introduce architectural choices, abstractions, or frontend patterns that may fight the framework. Reviews code from an opinionated DHH perspective.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/julik-frontend-races-reviewer.md

@@ -2,7 +2,7 @@
 name: julik-frontend-races-reviewer
 description: Conditional code-review persona, selected when the diff touches async UI code, Stimulus/Turbo lifecycles, or DOM-timing-sensitive frontend behavior. Reviews code for race conditions and janky UI failure modes.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/kieran-python-reviewer.md

@@ -2,7 +2,7 @@
 name: kieran-python-reviewer
 description: Conditional code-review persona, selected when the diff touches Python code. Reviews changes with Kieran's strict bar for Pythonic clarity, type hints, and maintainability.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/kieran-rails-reviewer.md

@@ -2,7 +2,7 @@
 name: kieran-rails-reviewer
 description: Conditional code-review persona, selected when the diff touches Rails application code. Reviews Rails changes with Kieran's strict bar for clarity, conventions, and maintainability.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/kieran-typescript-reviewer.md

@@ -2,7 +2,7 @@
 name: kieran-typescript-reviewer
 description: Conditional code-review persona, selected when the diff touches TypeScript code. Reviews changes with Kieran's strict bar for type safety, clarity, and maintainability.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/maintainability-reviewer.md

@@ -2,7 +2,7 @@
 name: maintainability-reviewer
 description: Always-on code-review persona. Reviews code for premature abstraction, unnecessary indirection, dead code, coupling between unrelated modules, and naming that obscures intent.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/performance-reviewer.md

@@ -2,7 +2,7 @@
 name: performance-reviewer
 description: Conditional code-review persona, selected when the diff touches database queries, loop-heavy data transforms, caching layers, or I/O-intensive paths. Reviews code for runtime performance and scalability issues.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/previous-comments-reviewer.md

@@ -2,7 +2,7 @@
 name: previous-comments-reviewer
 description: Conditional code-review persona, selected when reviewing a PR that has existing review comments or review threads. Checks whether prior feedback has been addressed in the current diff.
 tools: Read, Grep, Glob, Bash
-color: yellow
+color: warning
 
 ---
 

package/agents/review/project-standards-reviewer.md

@@ -2,7 +2,7 @@
 name: project-standards-reviewer
 description: Always-on code-review persona. Audits changes against the project's own AGENTS.md standards -- frontmatter rules, reference inclusion, naming conventions, cross-platform portability, and tool selection policies.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 
 ---
 

package/agents/review/reliability-reviewer.md

@@ -2,7 +2,7 @@
 name: reliability-reviewer
 description: Conditional code-review persona, selected when the diff touches error handling, retries, circuit breakers, timeouts, health checks, background jobs, or async handlers. Reviews code for production reliability and failure modes.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/security-reviewer.md

@@ -2,7 +2,7 @@
 name: security-reviewer
 description: Conditional code-review persona, selected when the diff touches auth middleware, public endpoints, user input handling, or permission checks. Reviews code for exploitable vulnerabilities.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 mode: subagent
 temperature: 0.1
 ---

package/agents/review/testing-reviewer.md

@@ -2,7 +2,7 @@
 name: testing-reviewer
 description: Always-on code-review persona. Reviews code for test coverage gaps, weak assertions, brittle implementation-coupled tests, and missing edge case coverage.
 tools: Read, Grep, Glob, Bash
-color: blue
+color: info
 
 ---
 

package/agents/workflow/lint.md

@@ -1,7 +1,7 @@
 ---
 name: lint
 description: Use this agent when you need to run linting and code quality checks on Ruby and ERB files. Run before pushing to origin.
-color: yellow
+color: warning
 mode: subagent
 temperature: 0.1
 ---

package/agents/workflow/pr-comment-resolver.md

@@ -1,7 +1,7 @@
 ---
 name: pr-comment-resolver
 description: "Evaluates and resolves one or more related PR review threads -- assesses validity, implements fixes, and returns structured summaries with reply text. Spawned by the resolve-pr-feedback skill."
-color: blue
+color: info
 ---
 
 You resolve PR review threads. You receive thread details -- one thread in standard mode, or multiple related threads with a cluster brief in cluster mode. Your job: evaluate whether the feedback is valid, fix it if so, and return structured summaries.

package/dist/cli.js

@@ -6,7 +6,7 @@ import {
   findCommandsInDir,
   findSkillsInDir,
   getConfigPaths
-} from "./index-488txzkn.js";
+} from "./index-d5ewqz8w.js";
 
 // src/cli.ts
 import fs from "fs";

package/dist/{index-488txzkn.js → index-d5ewqz8w.js}

@@ -856,7 +856,7 @@ var DEFAULT_CONFIG = {
   agents: {},
   categories: {}
 };
-var SECURITY_OVERLAY_FIELDS = new Set(["permission", "skills"]);
+var SECURITY_OVERLAY_FIELDS = new Set(["model", "permission", "skills"]);
 function isErrorWithCode(error) {
   return error instanceof Error && "code" in error;
 }

package/dist/index.js

@@ -12,7 +12,7 @@ import {
   loadConfig,
   loadConfigWithSources,
   parseFrontmatter
-} from "./index-488txzkn.js";
+} from "./index-d5ewqz8w.js";
 
 // src/index.ts
 import fs4 from "fs";
@@ -287,7 +287,7 @@ function validateTopP(sourcePath, keyPath, value) {
   }
 }
 function validatePositiveInteger(sourcePath, keyPath, value) {
-  if (!Number.isInteger(value) || value < 1) {
+  if (typeof value !== "number" || !Number.isInteger(value) || value < 1) {
     throwConfigError(sourcePath, keyPath, "must be a positive integer");
   }
 }
@@ -734,28 +734,20 @@ function registerSkillsPaths(config, skillsDir) {
 var SINGLETON_KEY = Symbol.for("systematic.singleton.v1");
 async function plugInOnce({
   doInit,
-  onDuplicate,
   pid
 }) {
   const currentPid = pid ?? process.pid;
   const g = globalThis;
   const existing = g[SINGLETON_KEY];
   if (existing && existing.pid === currentPid) {
-    if (!existing.warned) {
-      existing.warned = true;
-      try {
-        onDuplicate?.(currentPid);
-      } catch {}
-    }
-    await existing.hooksPromise;
-    return { isFirst: false, hooks: {} };
+    const hooks2 = await existing.hooksPromise;
+    return { isFirst: false, hooks: hooks2 };
   }
   const hooksPromise = doInit();
   g[SINGLETON_KEY] = {
     pid: currentPid,
     loadedAt: Date.now(),
-    hooksPromise,
-    warned: false
+    hooksPromise
   };
   const hooks = await hooksPromise;
   return { isFirst: true, hooks };
@@ -1004,18 +996,7 @@ var initializePlugin = async ({ client, directory }) => {
 };
 var SystematicPlugin = async (input) => {
   const { hooks } = await plugInOnce({
-    doInit: () => initializePlugin(input),
-    onDuplicate: (pid) => {
-      const message = `[systematic] duplicate factory invocation in same process (pid=${pid}); skipping duplicate registration. Multiple opencode.json sources may list this plugin.`;
-      console.warn(message);
-      input.client.app.log({
-        body: {
-          service: "systematic",
-          level: "warn",
-          message
-        }
-      }).catch(() => {});
-    }
+    doInit: () => initializePlugin(input)
   });
   return hooks;
 };

package/dist/lib/plugin-singleton.d.ts

@@ -11,25 +11,17 @@
  *
  * On the first invocation `doInit` runs and the resulting hooks promise
  * is cached on `globalThis`; the caller receives `{ isFirst: true, hooks }`.
- * On every subsequent invocation in the same PID `doInit` is skipped, the
- * cached promise is awaited (so sticky rejections still propagate),
- * `onDuplicate` fires exactly once, and the caller receives
- * `{ isFirst: false, hooks: {} as T }`. Across PIDs the guard is treated
- * as absent and init runs fresh — `globalThis` is per-process, but the
- * explicit PID check adds defensive belt-and-suspenders against any
- * state-leakage edge case.
+ * On every subsequent invocation in the same PID `doInit` is skipped and
+ * the cached resolved hooks are returned directly to every caller.
+ * Across PIDs the guard is treated as absent and init runs fresh —
+ * `globalThis` is per-process, but the explicit PID check adds defensive
+ * belt-and-suspenders against any state-leakage edge case.
  *
- * **Why empty hooks on duplicate invocations.** A whole-hooks singleton
- * that returns the same hooks reference to both invocations does not
- * deduplicate host-side tool registration: OpenCode iterates each plugin
- * source's returned hook surface and registers every tool entry it finds,
- * even when two sources return the same JS reference. Returning `{}` from
- * the duplicate path is the only shape that prevents host-side double
- * registration of `systematic_skill`, the `config` hook, and the
- * `experimental.chat.system.transform` hook. The Phase 0 follow-up probe
- * (see `docs/plans/2026-05-01-001-fix-idempotent-plugin-registration-plan.md`)
- * verified the duplicate `systematic_skill` entry in OpenCode's
- * `client.tool.list(...)` output, which is the LLM-visible tool catalog.
+ * The singleton returns the same hooks reference to every caller within a
+ * process — first and duplicate alike. OpenCode may register the same hook
+ * surface once per configured plugin source; that is preferable to suppressing
+ * duplicates with an empty object because every source keeps the full tools,
+ * commands, skills, and hooks surface.
  *
  * **Known limitation — rejected init is sticky.** If `doInit()` rejects,
  * the rejected promise is stored on `globalThis` and every subsequent
@@ -40,37 +32,27 @@
 export interface PlugInOnceOptions<T> {
     /** Heavy init work that should run at most once per process. */
     doInit: () => Promise<T>;
-    /**
-     * Called exactly once on the first duplicate invocation in the same
-     * process. Subsequent duplicates are silent. Receives the same `pid`
-     * value the guard used for its identity check (so test overrides flow
-     * through faithfully). Implementations must not throw; fire-and-forget
-     * side effects (logging, metrics) are expected. Synchronous exceptions
-     * are swallowed defensively.
-     */
-    onDuplicate?: (pid: number) => void;
     /** Test override; defaults to `process.pid`. */
     pid?: number;
 }
 /**
  * Result envelope for `plugInOnce(...)`.
  *
- * - `isFirst: true` — caller should return `hooks` to OpenCode.
- * - `isFirst: false` — caller MUST return `hooks` (which is an empty `{}`)
- *   so the host loader does not register tools or hooks twice.
+ * - `isFirst: true` — caller was the first invocation in this process.
+ * - `isFirst: false` — `doInit` was skipped; the cached result is returned.
  *
- * Callers that just `return result.hooks` do the right thing in both
- * cases without needing to inspect `isFirst`.
+ * In both cases `hooks` is the real resolved value of `doInit()`. Callers
+ * return `result.hooks` unconditionally without inspecting `isFirst`.
  */
 export interface PlugInOnceResult<T> {
     isFirst: boolean;
     hooks: T;
 }
 /**
- * Run `doInit` at most once per process; on duplicate invocations resolve to
- * empty hooks so the OpenCode host does not double-register tools and hooks.
+ * Run `doInit` at most once per process; on duplicate invocations return the
+ * cached real hook surface so every config source sees the same surface.
  */
-export declare function plugInOnce<T>({ doInit, onDuplicate, pid, }: PlugInOnceOptions<T>): Promise<PlugInOnceResult<T>>;
+export declare function plugInOnce<T>({ doInit, pid, }: PlugInOnceOptions<T>): Promise<PlugInOnceResult<T>>;
 /**
  * Test-only: clear the singleton state so the next invocation re-runs
  * init. Must not be called in production code paths.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fro.bot/systematic",
-  "version": "2.9.0",
+  "version": "2.9.2",
   "description": "Structured engineering workflows for OpenCode",
   "type": "module",
   "homepage": "https://fro.bot/systematic",