contextos-agents 2.3.1 → 2.3.2

package/.agents/generated/claude/skills/context-os/rules.yaml

@@ -1,135 +1,8 @@
-# Rule Engine
-# Conditional logic for context compilation based on project profile and task type
-
-rules:
-  # ═══════════════════════════════════════
-  # Profile-based rules
-  # ═══════════════════════════════════════
-
-  - name: mvp-minimal
-    description: MVP projects skip heavy infrastructure
-    if:
-      profile: mvp
-    then:
-      exclude_skills: [microservices, ddd, kubernetes, monitoring, cicd]
-      exclude_docs: [DEPLOYMENT.md]
-      prefer_skills: [sqlite, simple-auth, minimal-architecture]
-      max_doc_depth: 2  # Only Level 1 + Level 2
-
-  - name: enterprise-strict
-    description: Enterprise projects require full documentation and rigor
-    if:
-      profile: enterprise
-    then:
-      require_skills: [ddd, security, testing, cicd]
-      require_docs: [ARCHITECTURE.md, DATABASE.md, API.md, DECISIONS]
-      enforce_adr: true  # Every architectural decision must be recorded
-      enforce_testing: true
-      min_doc_depth: 3  # All levels required
-
-  - name: hackathon-speed
-    description: Hackathon mode — maximum speed, minimum ceremony
-    if:
-      profile: hackathon
-    then:
-      exclude_skills: [kubernetes, monitoring, cicd, ddd, microservices]
-      exclude_docs: [DEPLOYMENT.md, ROADMAP.md]
-      prefer_skills: [sqlite, simple-auth]
-      skip_review: true
-      max_doc_depth: 1  # Vision only
-
-  - name: startup-balanced
-    description: Startup balance between speed and quality
-    if:
-      profile: startup
-    then:
-      exclude_skills: [kubernetes, ddd]
-      prefer_skills: [postgres, jwt-auth, docker]
-      enforce_adr: false
-      max_doc_depth: 2
-
-  # ═══════════════════════════════════════
-  # Task-based rules
-  # ═══════════════════════════════════════
-
-  - name: frontend-task
-    description: Frontend tasks don't need database or deployment docs
-    if:
-      task_type: frontend
-    then:
-      load_docs: [UI.md, ARCHITECTURE.md, API.md]
-      skip_docs: [DATABASE.md, DEPLOYMENT.md]
-      load_skill_categories: [frontend, design]
-      skip_skill_categories: [backend, infrastructure]
-
-  - name: backend-task
-    description: Backend tasks don't need UI docs
-    if:
-      task_type: backend
-    then:
-      load_docs: [ARCHITECTURE.md, DATABASE.md, API.md]
-      skip_docs: [UI.md]
-      load_skill_categories: [backend, architecture]
-      skip_skill_categories: [design]
-
-  - name: architecture-task
-    description: Architecture tasks load everything at high level
-    if:
-      task_type: architecture
-    then:
-      load_docs: [PRD.md, ARCHITECTURE.md, DATABASE.md, API.md, PROJECT_GRAPH.md]
-      load_skill_categories: [architecture]
-      skip_skill_categories: [design]
-
-  - name: bugfix-task
-    description: Bugfixes need minimal context — focus on affected module
-    if:
-      task_type: bugfix
-    then:
-      load_docs: [PROJECT_GRAPH.md]  # Find affected module
-      max_doc_depth: 1
-      skip_docs: [PRD.md, ROADMAP.md]
-
-  - name: refactor-task
-    description: Refactoring needs architecture context
-    if:
-      task_type: refactor
-    then:
-      load_docs: [ARCHITECTURE.md, PROJECT_GRAPH.md]
-      load_skill_categories: [architecture]
-
-  # ═══════════════════════════════════════
-  # Stack-based rules
-  # ═══════════════════════════════════════
-
-  - name: react-ecosystem
-    description: React projects auto-load TypeScript
-    if:
-      skill_loaded: react
-    then:
-      auto_load: [typescript]
-      suggest: [tailwind, react-query]
-
-  - name: nextjs-ecosystem
-    description: Next.js implies React + TypeScript + SSR patterns
-    if:
-      skill_loaded: nextjs
-    then:
-      auto_load: [react, typescript]
-      suggest: [prisma, next-auth, tailwind]
-
-  - name: fastapi-ecosystem
-    description: FastAPI implies Python + Pydantic
-    if:
-      skill_loaded: fastapi
-    then:
-      auto_load: [python, pydantic]
-      suggest: [postgres, docker, testing]
-
-  - name: no-conflicts
-    description: Prevent incompatible frameworks
-    if:
-      any_loaded: [react, vue, angular, svelte]
-    then:
-      conflict_check: true
-      max_frontend_frameworks: 1
+# Reference-only illustration. The CLI does not interpret this file as policy.
+status: reference-only
+purpose: Document proportional context selection; use supported profile commands.
+principles:
+  - select relevant installed skills
+  - preserve mandatory safety guidance
+  - inspect missing-skill and budget warnings
+  - verify behavior separately from document structure

package/.agents/generated/claude/skills/engineering-workflow/EXAMPLES.md

@@ -1,57 +1,22 @@
-# engineering-workflow Examples — Anti-patterns vs ContextOS Standard
+# Workflow examples
 
-## Example 1: Handling a New Feature Request
+## Routine change
 
-### Anti-pattern: Jumping Straight to Code
+Correct a README typo, inspect the diff, and run the relevant Markdown check.
+A spec, role banner, synthetic unit test, or repeated approval adds no evidence.
 
-```text
-User: "Add a user referral system."
-Agent: Immediately creates src/referral.js, starts writing database queries, guesses schema,
-and misses requirements like rate limiting, expiry dates, and fraud prevention.
-```
+## Feature slices
 
-### Best practice: ContextOS Standard (DEFINE -> PLAN -> BUILD)
+1. Create a minimal referral claim path through storage, service, API, and UI.
+   Verify one valid claim and one rejected claim.
+2. Add expiry and repeated-claim handling through the same path. Verify both.
+3. Add the required abuse controls and relevant integration checks.
 
-```markdown
-[DOMAIN: Full-Stack] [PHASE: Define] [ROLE: Product Manager]
-Skills loaded: engineering-workflow, interview-me
+Do not split every feature into all storage first, all routes second, and all UI
+last unless the architecture or dependencies actually require that order.
 
-## Feature Spec: User Referral System
-### Why (Problem)
-Increase user acquisition through organic word-of-mouth incentives.
+## Review request
 
-### Scope
-In-Scope:
-- Unique referral code generation per registered user
-- Referral code attribution on signup
-- Credit reward trigger after first completed purchase
-Out-of-Scope:
-- Multi-tier MLM rewards
-- Cash payout integrations
-
-### Acceptance Criteria
-- [ ] Given a registered user, when visiting /referrals, then unique code is displayed.
-- [ ] Given a new user with code, when signing up, then referrer_id is stored with status 'pending'.
-```
-
----
-
-## Example 2: Atomic Task Execution in PLAN Phase
-
-### Anti-pattern: Monolithic Mega-Task
-
-```text
-Task: "Implement entire referral system end-to-end in one shot."
-Result: 15 files modified simultaneously, uncompilable intermediate state, untestable diff.
-```
-
-### Best practice: ContextOS Standard (Atomic Tasks with Test Gate)
-
-```markdown
-[DOMAIN: Full-Stack] [PHASE: Plan] [ROLE: Architect]
-Atomic Tasks:
-1. Database migration: referrals and referral_rewards tables + indexes. (Test: Migration rollback & apply)
-2. Domain service: ReferralService.createCode() and ReferralService.claimCode(). (Test: Unit tests)
-3. API route: POST /api/referrals/claim with Zod validation. (Test: Supertest integration)
-4. UI component: <ReferralCard /> with copy button. (Test: RTL component test)
-```
+Inspect the code and callers, reproduce a failure when feasible, report an
+exploit or incorrect-result scenario and its scope. A review request by itself
+is not a request to publish, message others, or rewrite the feature.

package/.agents/generated/claude/skills/engineering-workflow/SKILL.md

@@ -6,28 +6,28 @@ Define the outcome, plan substantial changes, implement, verify, review, and rep
 
 ## When to Use
 
-Implementation, debugging, reviews, and release preparation. Routine maintenance and diagnostics can proceed directly with relevant checks.
+Implementation, debugging, reviews, and release preparation. Routine maintenance and diagnostics use targeted checks.
 
 ## Rules & Patterns
 
-Establish acceptance criteria for substantial or ambiguous features. Ask only for missing decisions that affect scope or safety. An explicit implementation request authorizes ordinary reversible work. Preserve unrelated changes. Verify behavior before reporting completion. Publishing and external messages need authorization for that action.
+Establish acceptance criteria for substantial or ambiguous work. Ask only for missing decisions affecting scope, safety, or external actions. An implementation request authorizes ordinary reversible work. Inspect affected code and callers, preserve unrelated changes, and verify behavior before reporting completion. Roles are optional.
 
-Read [references/workflow.md](references/workflow.md) for detailed procedures and examples only when needed.
+Read [references/workflow.md](references/workflow.md) for procedures when needed.
 
 ## Code Examples
 
-A README typo needs an edit and relevant formatting check. An authentication feature needs access boundaries, failure cases, implementation, and behavioral verification.
+A README typo needs a small edit and formatting check. An authorization fix needs an allowed-user case and a denied-user regression.
 
 ## Validation Checklist
 
-- [ ] The requested outcome is handled.
-- [ ] Relevant verification and safety boundaries are preserved.
-- [ ] Limitations are stated.
+- [ ] The requested outcome and applicable failure cases are checked.
+- [ ] Evidence names commands, results, scope, and limitations.
+- [ ] Unrelated changes and existing authorization are preserved.
 
 ## Common Mistakes
 
-Repeated approval after authorization; unnecessary ceremonies for routine edits; treating role labels or string checks as behavioral proof.
+Repeated approval after authorization; full ceremonies for routine edits; treating headings, role labels, or schema checks as behavioral proof.
 
 ## Integration Notes
 
-Load relevant domain skills and supporting resources on demand. Compatibility identifiers remain available.
+Use security for sensitive boundaries, ponytail-mindset for implementation complexity, and context-os for compiler/configuration work. gstack-roles is a compatibility alias.

package/.agents/generated/claude/skills/engineering-workflow/TROUBLESHOOTING.md

@@ -1,19 +1,11 @@
-# engineering-workflow Troubleshooting & Common Mistakes
-
-## 1. Premature Code Generation
-
-- **Symptom**: Agent starts spitting out code blocks while the user is still clarifying requirements.
-- **Root Cause**: Failure to enforce the IRON RULE of Phase 1 (DEFINE) and Phase 2 (PLAN).
-- **Fix**: Halt code output immediately. Announce `[PHASE: Define]` or `[PHASE: Plan]` and provide the structured spec or task breakdown for user sign-off.
-
-## 2. Blast Radius Creep
-
-- **Symptom**: A simple bugfix in one module modifies 8 unrelated configuration and styling files.
-- **Root Cause**: Missing isolation boundaries and speculative cleanup.
-- **Fix**: Restrict edits strictly to files explicitly declared in the current atomic task's plan.
-
-## 3. Unverified Claims of Completion
-
-- **Symptom**: Agent reports "Task complete! Everything is working" without running tests or builds.
-- **Root Cause**: Skipping Phase 4 (VERIFY).
-- **Fix**: Always execute tests (`npm test`, validator, compiler) and quote actual terminal exit codes and outputs before declaring completion.
+# Workflow troubleshooting
+
+- Missing material requirement: inspect existing conventions, then ask for the
+  remaining decision. Existing implementation authorization remains valid.
+- Scope growth: inspect why the caller must change, update the scoped plan, and
+  preserve unrelated edits. Do not restrict a necessary fix to an obsolete list.
+- Unverified completion: run relevant behavior checks or report what remains
+  unverified. A passing document validator is not implementation evidence.
+- Excess ceremony: use the routine fast track for a typo, formatter, or diagnostic.
+- Failed gate: read the actual failure; distinguish introduced regressions from
+  pre-existing failures instead of silently dropping the gate.

package/.agents/generated/claude/skills/engineering-workflow/VALIDATION.json

@@ -1,12 +1,123 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
+  "x-contextos-evidence-contract": 1,
+  "title": "Scoped verification evidence",
+  "description": "Report shape and outcome consistency only; command execution and agent behavior require separate evidence.",
   "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "status",
+    "checks",
+    "limitations"
+  ],
   "properties": {
-    "rules_followed": {
-      "type": "boolean"
+    "status": {
+      "enum": [
+        "verified",
+        "partial",
+        "not_run"
+      ]
+    },
+    "checks": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "command",
+          "exitCode",
+          "scope"
+        ],
+        "properties": {
+          "command": {
+            "type": "string",
+            "minLength": 1
+          },
+          "exitCode": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "scope": {
+            "type": "string",
+            "minLength": 1
+          }
+        }
+      }
+    },
+    "limitations": {
+      "type": "array",
+      "items": {
+        "type": "string",
+        "minLength": 1
+      }
     }
   },
-  "required": [
-    "rules_followed"
+  "allOf": [
+    {
+      "if": {
+        "properties": {
+          "status": {
+            "const": "verified"
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "checks": {
+            "minItems": 1,
+            "items": {
+              "properties": {
+                "exitCode": {
+                  "const": 0
+                }
+              }
+            }
+          }
+        }
+      }
+    },
+    {
+      "if": {
+        "properties": {
+          "status": {
+            "enum": [
+              "partial",
+              "not_run"
+            ]
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "limitations": {
+            "minItems": 1
+          }
+        }
+      }
+    },
+    {
+      "if": {
+        "properties": {
+          "status": {
+            "const": "not_run"
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "checks": {
+            "items": {
+              "properties": {
+                "exitCode": {
+                  "type": "null"
+                }
+              }
+            }
+          }
+        }
+      }
+    }
   ]
 }