@fro.bot/systematic 3.13.0 → 3.13.2

package/package.json

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

package/skills/ce-compound/references/yaml-schema.md

@@ -16,7 +16,14 @@ The `problem_type` determines which **track** applies. Each track has different
 | Track | problem_types | Description |
 |-------|--------------|-------------|
 | **Bug** | `build_error`, `test_failure`, `runtime_error`, `performance_issue`, `database_issue`, `security_issue`, `ui_bug`, `integration_issue`, `logic_error` | Defects and failures that were diagnosed and fixed |
-| **Knowledge** | `best_practice`, `documentation_gap`, `workflow_issue`, `developer_experience` | Practices, patterns, workflow improvements, and documentation |
+| **Knowledge** | `best_practice`, `documentation_gap`, `workflow_issue`, `developer_experience`, `architecture_pattern`, `design_pattern`, `tooling_decision`, `convention` | Practices, patterns, workflow improvements, and documentation |
+
+Prefer the narrowest applicable value. `best_practice` is the fallback when no narrower knowledge-track value fits.
+
+- `architecture_pattern` — structural decisions about how components relate
+- `design_pattern` — reusable solutions to recurring design problems
+- `tooling_decision` — choices about tools, libraries, or build infrastructure
+- `convention` — agreed-upon naming, formatting, or style rules
 
 ## Required Fields (both tracks)
 
@@ -35,6 +42,8 @@ Required:
 
 ## Knowledge Track Fields
 
+Applies to every knowledge-track `problem_type` listed in the Tracks table above.
+
 No additional required fields beyond the shared ones. All fields below are optional:
 
 - **applies_when**: Conditions or situations where this guidance applies
@@ -73,6 +82,14 @@ Docs created before the track system may have `symptoms`/`root_cause`/`resolutio
 - `workflow_issue` -> `docs/solutions/workflow-issues/`
 - `best_practice` -> `docs/solutions/best-practices/`
 - `documentation_gap` -> `docs/solutions/documentation-gaps/`
+- `architecture_pattern` -> `docs/solutions/best-practices/`
+- `design_pattern` -> `docs/solutions/best-practices/`
+- `tooling_decision` -> `docs/solutions/best-practices/`
+- `convention` -> `docs/solutions/best-practices/`
+
+The four narrower knowledge-track types share the `best-practices/` directory rather than each
+getting their own. That matches where such docs are already filed, and avoids single-document
+directories that fragment search.
 
 ## Validation Rules
 

package/skills/ce-compound-refresh/references/schema.yaml

@@ -23,12 +23,16 @@ tracks:
       - integration_issue
       - logic_error
   knowledge:
-    description: "Best practices, workflow improvements, patterns, and documentation"
+    description: "Best practices, workflow improvements, patterns, conventions, and documentation"
     problem_types:
       - best_practice
       - documentation_gap
       - workflow_issue
       - developer_experience
+      - architecture_pattern
+      - design_pattern
+      - tooling_decision
+      - convention
 
 # --- Fields required by BOTH tracks -----------------------------------------
 required_fields:
@@ -57,7 +61,18 @@ required_fields:
       - workflow_issue
       - best_practice
       - documentation_gap
-    description: "Primary category — determines track (bug vs knowledge)"
+      - architecture_pattern
+      - design_pattern
+      - tooling_decision
+      - convention
+    description: >-
+      Primary category — determines track (bug vs knowledge).
+      Prefer the narrowest applicable value; best_practice is the fallback
+      when no narrower knowledge-track value fits.
+      architecture_pattern: structural decisions about how components relate.
+      design_pattern: reusable solutions to recurring design problems.
+      tooling_decision: choices about tools, libraries, or build infrastructure.
+      convention: agreed-upon naming, formatting, or style rules.
 
   component:
     type: enum
@@ -220,3 +235,13 @@ validation_rules:
   - "date must match YYYY-MM-DD format"
   - "rails_version, if provided, must match X.Y.Z format and only applies to bug-track docs"
   - "tags should be lowercase and hyphen-separated"
+  - |-
+    YAML quoting: scalar values that contain ' #' (space-hash) must be
+    double-quoted to prevent silent YAML comment truncation (the YAML parser
+    treats ' #' as an inline comment, silently dropping the rest of the value
+    with parseError: false). Example: problem: "cache miss # under load".
+  - |-
+    YAML quoting: array-of-strings frontmatter items must be double-quoted when
+    the value starts with a YAML reserved indicator (e.g., '{', '[', '|', '>',
+    '!', '&', '*', '?', ':', '-') or contains ': ' (colon-space). Example:
+    symptoms: - "[mdx-js/rollup] Could not parse expression"

package/skills/ce-compound-refresh/references/yaml-schema.md

@@ -16,7 +16,14 @@ The `problem_type` determines which **track** applies. Each track has different
 | Track | problem_types | Description |
 |-------|--------------|-------------|
 | **Bug** | `build_error`, `test_failure`, `runtime_error`, `performance_issue`, `database_issue`, `security_issue`, `ui_bug`, `integration_issue`, `logic_error` | Defects and failures that were diagnosed and fixed |
-| **Knowledge** | `best_practice`, `documentation_gap`, `workflow_issue`, `developer_experience` | Practices, patterns, workflow improvements, and documentation |
+| **Knowledge** | `best_practice`, `documentation_gap`, `workflow_issue`, `developer_experience`, `architecture_pattern`, `design_pattern`, `tooling_decision`, `convention` | Practices, patterns, workflow improvements, and documentation |
+
+Prefer the narrowest applicable value. `best_practice` is the fallback when no narrower knowledge-track value fits.
+
+- `architecture_pattern` — structural decisions about how components relate
+- `design_pattern` — reusable solutions to recurring design problems
+- `tooling_decision` — choices about tools, libraries, or build infrastructure
+- `convention` — agreed-upon naming, formatting, or style rules
 
 ## Required Fields (both tracks)
 
@@ -35,6 +42,8 @@ Required:
 
 ## Knowledge Track Fields
 
+Applies to every knowledge-track `problem_type` listed in the Tracks table above.
+
 No additional required fields beyond the shared ones. All fields below are optional:
 
 - **applies_when**: Conditions or situations where this guidance applies
@@ -73,6 +82,14 @@ Docs created before the track system may have `symptoms`/`root_cause`/`resolutio
 - `workflow_issue` -> `docs/solutions/workflow-issues/`
 - `best_practice` -> `docs/solutions/best-practices/`
 - `documentation_gap` -> `docs/solutions/documentation-gaps/`
+- `architecture_pattern` -> `docs/solutions/best-practices/`
+- `design_pattern` -> `docs/solutions/best-practices/`
+- `tooling_decision` -> `docs/solutions/best-practices/`
+- `convention` -> `docs/solutions/best-practices/`
+
+The four narrower knowledge-track types share the `best-practices/` directory rather than each
+getting their own. That matches where such docs are already filed, and avoids single-document
+directories that fragment search.
 
 ## Validation Rules