@fro.bot/systematic 3.12.0 → 3.12.2

package/agents/document-review/feasibility-reviewer.md

@@ -10,7 +10,7 @@ You are a systems architect evaluating whether this plan can actually be built a
 
 ## What you check
 
-**"What already exists?"** -- Does the plan acknowledge existing code, services, and infrastructure? If it proposes building something new, does an equivalent already exist in the codebase? Does it assume greenfield when reality is brownfield? When the plan carries a Prior-Art Survey, verify that every named candidate resolves to real code, spot-check that its stated ownership matches what the code actually does, and confirm that a `build-new-within-scope` verdict's insufficiency reasons hold. Treat an absence claim as limited to the survey's stated scope and budget, not as repository-wide evidence. If the survey reports an equivalent, does the plan name the corresponding requirement or implementation-unit change? Citing an equivalent under related work without changing the design is a finding. This check requires reading the codebase alongside the plan.
+**"What already exists?"** -- Does the plan acknowledge existing code, services, and infrastructure? If it proposes building something new, does an equivalent already exist in the codebase? Does it assume greenfield when reality is brownfield? When the plan carries a Prior-Art Survey, verify that every named candidate resolves to real code, spot-check that its stated ownership matches what the code actually does, and confirm that a `build-new-within-scope` verdict's insufficiency reasons hold. For that verdict, inspect every `excluded_scopes` entry: if the concern plausibly belongs in an excluded scope, the survey's boundary is inadequate and return a finding. Treat an absence claim as limited to the survey's stated scope and budget, not as repository-wide evidence. If the survey reports an equivalent, does the plan name the corresponding requirement or implementation-unit change? Citing an equivalent under related work without changing the design is a finding. This check requires reading the codebase alongside the plan.
 
 **Architecture reality** -- Do proposed approaches conflict with the framework or stack? Does the plan assume capabilities the infrastructure doesn't have? If it introduces a new pattern, does it address coexistence with existing patterns?
 

package/agents/research/repo-research-analyst.md

@@ -159,13 +159,13 @@ Run this survey for every software-work concern, including shallow plans. Skip i
 2. Bound the search to a workspace or subtree using the existing Phase 0.1 and 0.1b detection logic above. For a monorepo, use the named workspace or service when the concern identifies one; otherwise report the workspace map and choose the smallest defensible subtree. State a finite search budget before searching, covering the search passes and candidate inspection depth you will use.
 3. Search the bounded scope for source, registrations, tests, schemas, and configuration that currently handle the trigger, effect, state, or integration boundary. Use the concern's synonyms and nearby domain terms, including terms discovered from filenames, symbols, registrations, and schemas.
 4. Collect every plausible candidate before assigning any disposition. For each candidate, describe what it owns in the vocabulary the code itself uses: use its symbols, module names, events, records, states, or boundaries rather than translating it into the request's vocabulary.
-5. Only after the candidate inventory is complete, disposition candidates and identify the strongest evidence. Preserve the stated scope and budget in the result, including whether the budget was exhausted.
+5. Only after the candidate inventory is complete, disposition candidates and identify the strongest evidence. Preserve the stated scope and budget in the result, including whether the budget was exhausted. If the verdict is `build-new-within-scope`, also record every adjacent scope you considered but deliberately did not search, with the reason for each exclusion. Emit `excluded_scopes: []` when the surveyed scope has no adjacent scopes; do not omit the field or use an empty list to mean that exclusions were not considered.
 
-The prior-art output must report the concern framing, surveyed workspace or subtree, freshness record, search budget, candidate inventory, and dispositions. Emit exactly one machine-checkable result using `skills/ce-plan/references/prior-art-survey-schema.json` as the contract. Use `schema_version: 1`. The `freshness` object must include at least one of `vcs_reference` (the current VCS reference for the surveyed scope, when available) or `scope_baseline` (a portable digest or compact baseline for the surveyed scope when VCS is unavailable); include both when both are available. Do not replace this record with prose.
+The prior-art output must report the concern framing, surveyed workspace or subtree, freshness record, search budget, candidate inventory, and dispositions. Emit exactly one machine-checkable result using `skills/ce-plan/references/prior-art-survey-schema.json` as the contract. Use `schema_version: 2`. The `freshness` object must include at least one of `vcs_reference` (the current VCS reference for the surveyed scope, when available) or `scope_baseline` (a portable digest or compact baseline for the surveyed scope when VCS is unavailable); include both when both are available. Do not replace this record with prose.
 
 ```json
 {
-  "schema_version": 1,
+  "schema_version": 2,
   "verdict": "reuse | extend | build-new-within-scope | unscoped | unresolved",
   "scope": "<workspace or subtree searched>",
   "freshness": {
@@ -185,6 +185,12 @@ The prior-art output must report the concern framing, surveyed workspace or subt
       "insufficiency_reason": "<required for build-new-within-scope candidates>"
     }
   ],
+  "excluded_scopes": [
+    {
+      "scope": "<adjacent scope considered but not searched>",
+      "reason": "<why this adjacent scope was deliberately not searched>"
+    }
+  ],
   "scopes_considered": ["<required for an unscoped verdict>"],
   "acceptance": {
     "accepted_by_user": true,
@@ -194,7 +200,7 @@ The prior-art output must report the concern framing, surveyed workspace or subt
 }
 ```
 
-Use exactly one verdict. `build-new-within-scope` requires at least one candidate, every candidate must have disposition `insufficient`, and every candidate must include `insufficiency_reason`. `unscoped` requires a non-empty `scopes_considered` list. `unresolved` requires at least one `undispositioned` candidate and must retain every disposition already reached. Include `acceptance` only when a user accepts an `unscoped` or `unresolved` verdict. An empty candidate list is the only representation of absence: keep it alongside the searched `scope` and `budget`, and never claim that no equivalent exists anywhere.
+Use exactly one verdict. `build-new-within-scope` requires at least one candidate, every candidate must have disposition `insufficient`, every candidate must include `insufficiency_reason`, and `excluded_scopes` must be present. Each excluded scope entry must include a non-blank `scope` and a reason; use `excluded_scopes: []` only when no adjacent scopes exist. `unscoped` requires a non-empty `scopes_considered` list. `unresolved` requires at least one `undispositioned` candidate and must retain every disposition already reached. Include `acceptance` only when a user accepts an `unscoped` or `unresolved` verdict. An empty candidate list is the only representation of absence: keep it alongside the searched `scope` and `budget`, and never claim that no equivalent exists anywhere.
 
 ---
 
@@ -283,11 +289,11 @@ Structure your findings as:
 ### Prior-Art Survey
 - Concern framing: trigger, effect, state, and integration boundary
 - A structured result conforming to `skills/ce-plan/references/prior-art-survey-schema.json`
-- `schema_version: 1` and a `freshness` record with at least one of `vcs_reference` or `scope_baseline`
+- `schema_version: 2` and a `freshness` record with at least one of `vcs_reference` or `scope_baseline`
 - Exactly one verdict: `reuse`, `extend`, `build-new-within-scope`, `unscoped`, or `unresolved`
 - The searched workspace or subtree in `scope`, plus bounded `budget` fields and whether the budget was exhausted
 - A complete `candidates` inventory with each path or symbol, code-vocabulary ownership description, and disposition
-- For `build-new-within-scope`, a non-empty candidate list whose candidates all explain their insufficiency
+- For `build-new-within-scope`, a non-empty candidate list whose candidates all explain their insufficiency, plus `excluded_scopes` entries naming adjacent scopes deliberately not searched and why (or an explicit empty list when none are adjacent)
 - For `unscoped`, a non-empty `scopes_considered` list; for `unresolved`, at least one `undispositioned` candidate while preserving reached dispositions
 - An optional `acceptance` record only when a user accepted an `unscoped` or `unresolved` verdict
 - Absence represented only by the searched scope, budget, and an empty candidate list; never assert an unbounded absence

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fro.bot/systematic",
-  "version": "3.12.0",
+  "version": "3.12.2",
   "description": "Compound-engineering loops for OpenCode, Pi, and Claude Code",
   "type": "module",
   "homepage": "https://fro.bot/systematic",

package/skills/ce-plan/SKILL.md

@@ -563,7 +563,7 @@ Omit `scopes_considered` unless the verdict is `unscoped`, and omit `acceptance`
 
 ```json
 {
-  "schema_version": 1,
+  "schema_version": 2,
   "verdict": "reuse | extend | build-new-within-scope | unscoped | unresolved",
   "scope": "<workspace or subtree searched>",
   "freshness": {

package/skills/ce-plan/references/prior-art-survey-schema.json

@@ -137,8 +137,8 @@
       ],
       "properties": {
         "schema_version": {
-          "const": 1,
-          "description": "Version discriminator for this survey contract."
+          "const": 2,
+          "description": "Version discriminator for this survey contract. Bumped to 2 when excluded_scopes became conditionally required for a build-new-within-scope verdict."
         },
         "verdict": {
           "$ref": "#/definitions/verdict"
@@ -176,6 +176,33 @@
           },
           "description": "Alternative scopes considered when no defensible survey scope could be selected."
         },
+        "excluded_scopes": {
+          "type": "array",
+          "minItems": 0,
+          "maxItems": 8,
+          "items": {
+            "type": "object",
+            "required": ["scope", "reason"],
+            "properties": {
+              "scope": {
+                "type": "string",
+                "minLength": 1,
+                "maxLength": 256,
+                "pattern": "\\S",
+                "description": "Adjacent scope considered but deliberately not searched."
+              },
+              "reason": {
+                "type": "string",
+                "minLength": 1,
+                "maxLength": 500,
+                "pattern": "\\S",
+                "description": "Why the adjacent scope was deliberately not searched."
+              }
+            },
+            "additionalProperties": false
+          },
+          "description": "Adjacent scopes considered but not searched, with a reason for each exclusion. An empty list explicitly means no adjacent scopes exist."
+        },
         "acceptance": {
           "$ref": "#/definitions/acceptance"
         }
@@ -191,6 +218,7 @@
             }
           },
           "then": {
+            "required": ["excluded_scopes"],
             "properties": {
               "candidates": {
                 "minItems": 1,

package/skills/ce-plan/references/universal-planning.md

@@ -28,7 +28,7 @@ Evaluate two things before planning:
 | Research need | Signals | Action |
 |--------------|---------|--------|
 | **None** | Generic, timeless, or conceptual plan (study curriculum methodology, project management approach, personal goal breakdown) | Skip research. Model knowledge is sufficient. After structuring the plan, offer: "I based this on general knowledge. Want me to search for [specific thing research would improve]?" — e.g., sourced recipes, current product recommendations, expert frameworks. Only if the user accepts. |
-| **Recommended** | Plan references specific locations, venues, dates, prices, schedules, seasonal availability, or current events — anything where stale information would break the plan (closed restaurants, changed prices, cancelled events, wrong seasonal dates). | Research before planning. Decompose into 2-5 focused research questions and dispatch parallel web searches. In OpenCode, use the Agent tool with `model: "haiku"` for each search to reduce cost. Collate findings before structuring the plan. |
+| **Recommended** | Plan references specific locations, venues, dates, prices, schedules, seasonal availability, or current events — anything where stale information would break the plan (closed restaurants, changed prices, cancelled events, wrong seasonal dates). | Research before planning. Decompose into 2-5 focused research questions and dispatch parallel web searches. Collate findings before structuring the plan. |
 
 When research is recommended, do it — don't just offer. Stale recommendations (closed restaurants, rethemed attractions, outdated prices) are worse than no recommendations. The user invoked `ce:plan` because they want a good plan, not a disclaimer about training data.
 

package/skills/ce-work/SKILL.md

@@ -53,11 +53,16 @@ Determine how to proceed based on what was provided in `<input_document>`.
    - Check for a `Deferred to Implementation` or `Implementation-Time Unknowns` section — these are questions the planner intentionally left for you to resolve during execution. Note them before starting so they inform your approach rather than surprising you mid-task
    - Check for a `Scope Boundaries` section — these are explicit non-goals. Refer back to them if implementation starts pulling you toward adjacent work
    - Review any references or links provided in the plan
-   - If the plan has no `Prior-Art Survey` section at all, it predates this contract — proceed without rejecting it. Otherwise validate the section before environment setup: it must contain exactly one fenced `json` block, and that block must validate against `skills/ce-plan/references/prior-art-survey-schema.json`. Stop before setup when any of these conditions applies:
-     1. **Empty or non-unique survey block:** the section is present but empty, or contains zero or multiple fenced `json` blocks. Resolve it by rerunning planning and recording exactly one schema-conforming structured survey block.
-     2. **Malformed or schema-invalid survey block:** the sole block is not valid JSON or fails schema validation. Resolve it by replacing the block with one valid survey payload; prose or placeholder values do not satisfy the contract.
-     3. **Unaccepted failure verdict:** the validated verdict is `unscoped` or `unresolved` and the block has no recorded user acceptance for that same verdict. Resolve it by narrowing the scope, increasing the bounded budget, or getting the user to accept the uncertainty and recording matching acceptance.
-     4. **Stale surveyed scope:** the recorded scope has changed since the survey ran. Check only the workspace or subtree in `scope`, not the whole repository. When `freshness.vcs_reference` is present and usable VCS data is available, compare the current VCS reference or scoped diff; otherwise compare the current portable digest/baseline with `freshness.scope_baseline`. If neither comparison can be performed, stop and request a fresh survey or explicit re-baselining rather than assuming the result is fresh. Resolve a stale result by rerunning the survey against the current scope and updating the plan.
+   - Validate the plan's `Prior-Art Survey` state before environment setup using this exhaustive partition:
+     - **No survey section + recorded date before 2026-08-18:** the plan predates this contract; proceed without rejecting it. Read the plan's YAML frontmatter `date:` first. If that is absent, use only another explicit, trustworthy creation date defined by the host workflow or document format; a filename, location, or VCS record counts only when the host explicitly defines it as authoritative, and version control is never required.
+     - **No survey section + recorded date on or after 2026-08-18:** this is a contract failure; stop and name the missing section. Resolve it by rerunning planning and recording exactly one schema-conforming structured survey block.
+     - **No survey section + no determinable date:** do not guess whether the plan is old or recent. Stop and report that the grandfather condition cannot be established. Resolve it by recording a trustworthy plan date; if the date cannot be established, rerun planning and add the required survey rather than proceeding on an assumption.
+     - **Survey section present and valid:** it contains exactly one fenced `json` block, and that block validates against `skills/ce-plan/references/prior-art-survey-schema.json`; continue to the remaining workflow checks below. A present section is never grandfathered by its date.
+     - **Survey section present and invalid:** stop before setup when any of these conditions applies:
+       1. **Empty or non-unique survey block:** the section is present but empty, or contains zero or multiple fenced `json` blocks. Resolve it by rerunning planning and recording exactly one schema-conforming structured survey block.
+       2. **Malformed or schema-invalid survey block:** the sole block is not valid JSON or fails schema validation. Resolve it by replacing the block with one valid survey payload; prose or placeholder values do not satisfy the contract.
+       3. **Unaccepted failure verdict:** the validated verdict is `unscoped` or `unresolved` and the block has no recorded user acceptance for that same verdict. Resolve it by narrowing the scope, increasing the bounded budget, or getting the user to accept the uncertainty and recording matching acceptance.
+       4. **Stale surveyed scope:** the recorded scope has changed since the survey ran. Check only the workspace or subtree in `scope`, not the whole repository. When `freshness.vcs_reference` is present and usable VCS data is available, compare the current VCS reference or scoped diff; otherwise compare the current portable digest/baseline with `freshness.scope_baseline`. If neither comparison can be performed, stop and request a fresh survey or explicit re-baselining rather than assuming the result is fresh. Resolve a stale result by rerunning the survey against the current scope and updating the plan.
    - When refusing execution for a survey condition, name the condition that fired and the concrete resolution required; do not fail opaquely.
    - If the user explicitly asks for TDD, test-first, or characterization-first execution in this session, honor that request even if the plan has no `Execution note`
    - If anything is unclear or ambiguous, ask clarifying questions now