contextos-agents 2.3.1 → 2.3.2

package/.agents/generated/claude/skills/context-os/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"
+                }
+              }
+            }
+          }
+        }
+      }
+    }
   ]
 }

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

@@ -1,59 +1,10 @@
-# Skill Packs — pre-configured skill bundles
-# Users select a pack instead of individual skills
-
-packs:
-  fullstack-next:
-    name: "Next.js Full-Stack"
-    description: "Full-stack web app with Next.js, React, TypeScript, Tailwind, Prisma"
-    skills: [nextjs, react, typescript, tailwind, prisma, testing, security]
-    profile: startup
-    generates: [PRD, ARCHITECTURE, DATABASE, API, UI, TASKS, PROJECT_GRAPH]
-
-  fastapi-backend:
-    name: "FastAPI Backend"
-    description: "Python backend with FastAPI, PostgreSQL, Docker"
-    skills: [fastapi, python, pydantic, postgres, docker, testing, security, rest]
-    profile: startup
-    generates: [PRD, ARCHITECTURE, DATABASE, API, TASKS, PROJECT_GRAPH]
-
-  react-spa:
-    name: "React SPA"
-    description: "Single Page Application with React, TypeScript, Tailwind"
-    skills: [react, typescript, tailwind, performance, web-accessibility, testing]
-    profile: startup
-    generates: [PRD, ARCHITECTURE, API, UI, TASKS, PROJECT_GRAPH]
-
-  nestjs-enterprise:
-    name: "NestJS Enterprise"
-    description: "Enterprise-grade Node.js backend with NestJS, DDD, full testing"
-    skills: [nestjs, typescript, node, postgres, ddd, security, testing, cicd, docker]
-    profile: enterprise
-    generates: [PRD, ARCHITECTURE, DATABASE, API, TASKS, ROADMAP, PROJECT_GRAPH]
-
-  design-system:
-    name: "Design System"
-    description: "UI/UX design system with accessibility and performance"
-    skills: [ui-design, ux-design, web-accessibility, performance]
-    profile: startup
-    generates: [PRD, UI, TASKS]
-
-  mobile-react-native:
-    name: "React Native Mobile"
-    description: "Cross-platform mobile app with React Native"
-    skills: [react, typescript, react-native, performance, web-accessibility]
-    profile: startup
-    generates: [PRD, ARCHITECTURE, API, UI, TASKS, PROJECT_GRAPH]
-
-  hackathon-fast:
-    name: "Hackathon Quick Start"
-    description: "Fastest possible setup — SQLite, minimal architecture"
-    skills: [react, typescript, node, sqlite]
-    profile: hackathon
-    generates: [TASKS, PROJECT_GRAPH]
-
-  ai-saas:
-    name: "AI SaaS Platform"
-    description: "SaaS with AI features, auth, payments, analytics"
-    skills: [nextjs, react, typescript, tailwind, prisma, security, stripe, openai]
-    profile: startup
-    generates: [PRD, ARCHITECTURE, DATABASE, API, UI, ROADMAP, TASKS, PROJECT_GRAPH]
+# Reference-only illustration. This file does not install skills or generate docs.
+status: reference-only
+purpose: Illustrate task-focused grouping; inspect available catalog skills first.
+examples:
+  protected-api:
+    primary: [engineering-workflow, security]
+  compiler-maintenance:
+    primary: [engineering-workflow, context-os]
+  substantive-build:
+    primary: [engineering-workflow, ponytail-mindset]

package/.agents/generated/claude/skills/context-os/references/context-rules.md

@@ -1,68 +1,36 @@
-# Context Loading Rules
+# Context selection and budgeting
 
-## Task Type → Document Mapping
+## Inspect actual evidence
 
-| Task Type | Level 1 (Always) | Level 2 (If exists) | Level 3 (Per task) |
-| --- | --- | --- | --- |
-| **New project** | PRD, ROADMAP | ARCHITECTURE, DATABASE, API | UI, TASKS, all relevant skills |
-| **New feature** | PRD | ARCHITECTURE, API | PROJECT_GRAPH, relevant skills |
-| **Frontend** | — | ARCHITECTURE, API | UI, frontend skills |
-| **Backend** | — | ARCHITECTURE, DATABASE, API | backend skills |
-| **Database** | — | ARCHITECTURE, DATABASE | — |
-| **Bugfix** | — | — | PROJECT_GRAPH (affected module only) |
-| **Refactor** | — | ARCHITECTURE | PROJECT_GRAPH, affected skills |
-| **Review** | PRD | ARCHITECTURE | TASKS, all loaded skills |
-| **Deploy** | — | ARCHITECTURE | DEPLOYMENT, infrastructure skills |
+Supply a concrete task and affected paths to resolve. Inspect selected skills,
+reasons, risk, excluded candidates, and warnings. Select source files, callers,
+tests, relevant contracts, and active decisions manually as the task requires.
+Do not require a PRD, API document, database document, or module graph to exist.
+An absent schema change does not make database semantics irrelevant.
 
-## Skill Category → Document Mapping
+## Budget contract
 
-| Skill Category | Required Documents | Optional Documents |
-| --- | --- | --- |
-| `frontend` | UI.md, API.md | ARCHITECTURE.md |
-| `backend` | API.md, DATABASE.md | ARCHITECTURE.md |
-| `design` | UI.md | PRD.md |
-| `architecture` | ARCHITECTURE.md, DATABASE.md | PRD.md, API.md |
-| `infrastructure` | ARCHITECTURE.md | — |
-| `security` | ARCHITECTURE.md, API.md | DATABASE.md |
-| `testing` | API.md | ARCHITECTURE.md |
+The resolver estimates skill entrypoint length divided by 3.8, rounded up. It
+uses the requested positive --budget value or its current risk-tier default.
+References, tool output, system instructions, documents, and chat history are
+outside that estimate. Required safety guidance can exceed a soft budget and
+must produce an explicit overflow warning. No fixed 8000-token total or measured
+model token saving is promised.
 
-## Context Budget
+Trim irrelevant documents and select relevant sections first. Preserve user
+constraints and safety guidance. Inspect code dependencies and callers rather
+than limiting all investigations to exactly one import hop.
 
-To prevent context window overflow, apply these limits:
+## Aliases and unavailable skills
 
-| Priority | Max tokens | Content |
-| --- | --- | --- |
-| 1 (Critical) | 2000 | Current task description + relevant skill instructions |
-| 2 (Important) | 3000 | Architecture + API contracts for affected modules |
-| 3 (Context) | 2000 | Decision records + project graph (affected branch) |
-| 4 (Background) | 1000 | PRD summary + coding rules |
+context-manager resolves to context-os; gstack-roles resolves to
+engineering-workflow. The resolver avoids duplicate bodies and reports alias
+warnings. Installation and export still retain compatibility identifiers.
+Catalog skills are installed on demand; inspect unavailable-skill warnings.
 
-**Total budget: ~8000 tokens of context per task.**
+## Verification boundaries
 
-If context exceeds budget:
-
-1. Trim Level 1 docs to summaries only
-2. Load only affected sections of Level 2 docs
-3. Keep Level 3 (skills) at full detail — they contain the actual instructions
-
-## Module-Based Filtering
-
-When the Project Graph is available, use it to filter context:
-
-```
-Task: "Fix appointment reminder bug"
-  ↓
-Project Graph lookup: "reminder" → module: appointments
-  ↓
-Appointments depends_on: [patients, auth]
-  ↓
-Load only:
-  - appointments module docs
-  - auth module docs (dependency)
-  - API.md (appointments section only)
-  ↓
-Skip:
-  - patients module docs (not a dependency for this task)
-  - DATABASE.md (no schema change expected)
-  - UI.md (backend task)
-```
+compile validates manifests and builds the registry. validate checks source
+structure and sync. export --check inspects generated drift. Example tests run
+specific scenarios. None of these by itself proves live client instruction
+loading or improved model decisions.

package/.agents/generated/claude/skills/context-os/references/pipeline.md

@@ -1,119 +1,14 @@
-# Development Pipeline
-
-## The ContextOS Lifecycle
-
-```
-  ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
-  │  DEFINE  │ ──▶ │   PLAN   │ ──▶ │  BUILD   │ ──▶ │  VERIFY  │ ──▶ │  REVIEW  │ ──▶ │   SHIP   │
-  │          │     │          │     │          │     │          │     │          │     │          │
-  │ What to  │     │ How to   │     │ Write    │     │ Test &   │     │ Quality  │     │ Deploy & │
-  │ build    │     │ build it │     │ code     │     │ validate │     │ gates    │     │ document │
-  └──────────┘     └──────────┘     └──────────┘     └──────────┘     └──────────┘     └──────────┘
-       │                │                │                │                │                │
-  PRD.md           ARCHITECTURE.md  source code      tests           code review      DECISION.md
-  UI.md            DATABASE.md      components       coverage        self-review      changelog
-  ROADMAP.md       API.md           API routes       edge cases      security scan    deploy
-  PROJECT_GRAPH    TASKS.md         migrations       performance     a11y audit       release notes
-```
-
-## Stage Details
-
-### 1. DEFINE — "What are we building?"
-
-**Input:** User idea or feature request
-**Output:** PRD.md, UI.md, ROADMAP.md, PROJECT_GRAPH.md
-
-Process:
-
-1. Intent Analysis — parse the user's request
-2. Clarifying questions — fill gaps
-3. Generate PRD with clear requirements
-4. Generate UI spec if frontend is involved
-5. Create initial Project Graph
-
-**Context loaded:** None (this is the starting point)
-
-### 2. PLAN — "How will we build it?"
-
-**Input:** PRD.md
-**Output:** ARCHITECTURE.md, DATABASE.md, API.md, TASKS.md
-
-Process:
-
-1. Choose architecture based on profile + requirements
-2. Design database schema
-3. Define API contracts
-4. Break work into atomic tasks
-5. Update Project Graph with modules and features
-
-**Context loaded:** PRD.md, profiles/
-
-### 3. BUILD — "Write the code"
-
-**Input:** TASKS.md + relevant architecture docs
-**Output:** Source code, migrations, configurations
-
-Process:
-
-1. Pick next task from TASKS.md
-2. Context Compiler loads only relevant skills and docs
-3. Write code following loaded skill instructions
-4. Commit after each completed task
-5. Update Project Graph if structure changes
-
-**Context loaded:** Task-specific (via Context Manager)
-
-### 4. VERIFY — "Prove it works"
-
-**Input:** Source code
-**Output:** Tests, coverage reports
-
-Process:
-
-1. Write tests for new code
-2. Run existing tests — ensure nothing broke
-3. Check edge cases
-4. Verify performance (if applicable)
-
-**Context loaded:** Testing skills + API.md
-
-### 5. REVIEW — "Quality check"
-
-**Input:** Code changes (diff)
-**Output:** Review comments, approved changes
-
-Process:
-
-1. Self-review against coding standards
-2. Security scan (if security skill loaded)
-3. Accessibility audit (if frontend)
-4. Check against ARCHITECTURE.md — does this align?
-5. Check against Decision Records — does this contradict anything?
-
-**Context loaded:** ARCHITECTURE.md + relevant skills + decisions/
-
-### 6. SHIP — "Deploy and document"
-
-**Input:** Reviewed, tested code
-**Output:** Deployment, decision records, release notes
-
-Process:
-
-1. Record any architectural decisions made (ADR)
-2. Update ROADMAP.md — mark completed items
-3. Update TASKS.md — close completed tasks
-4. Deploy (if deployment skill loaded)
-5. Update Project Graph
-
-**Context loaded:** ROADMAP.md, TASKS.md, deployment skills
-
-## Profiles and Pipeline
-
-Different profiles customize the pipeline:
-
-| Profile | Skips | Adds |
-| --- | --- | --- |
-| **Hackathon** | REVIEW, detailed PLAN | Speed shortcuts |
-| **MVP** | Detailed REVIEW, DEPLOY | Quick iterations |
-| **Startup** | Heavy docs | Balance of speed and quality |
-| **Enterprise** | Nothing | ADR enforcement, security gates, full testing |
+# Compiler and engineering boundaries
+
+1. Inspect source manifests, declared entrypoints, overrides, and resources.
+2. Run compile to build the deterministic registry.
+3. Resolve the task with affected files and inspect risk, reasons, and warnings.
+4. Load selected entrypoints and relevant references on demand.
+5. Export supported agent projections and check drift.
+6. Run structural, example, and behavioral checks at their actual scope.
+
+For implementation use engineering-workflow's proportional lifecycle. Do not
+create a full suite of product documents or skip security review merely because
+a generic profile illustration says to do so. Profiles are runtime configuration
+from the supported profile commands and manifests, not rules interpreted from
+this skill's reference YAML files.

package/.agents/generated/claude/skills/context-os/references/project-graph.md

@@ -1,103 +1,14 @@
-# Project Graph
+# Workspace evidence graph
 
-The Project Graph is the **central nervous system** of ContextOS. It maps the entire project as a hierarchy:
+WorkspaceGraphBuilder discovers package manifests, dependency names, internal
+package links, language ecosystems, and known configuration files. The resolver
+uses nearest-package evidence to avoid unrelated monorepo stack signals. The
+graph is bounded and can report partial discovery.
 
-```
-Project
-  └── Module
-        └── Feature
-              └── Task
-                    └── File
-                          └── Skill
-```
+This graph is not a source-symbol AST, a feature/task map, or an automatic loader
+of sections from docs/PROJECT_GRAPH.md. Inspect source imports, callers, tests,
+and existing project documents explicitly for code impact analysis. A supplied
+Project Graph can help, but confirm its freshness against the current checkout.
 
-## Why Project Graph?
-
-Without a Project Graph, an AI agent sees a flat list of files. With it, the agent understands:
-
-1. **Impact analysis** — changing `calendar.ts` affects the Appointments module, which affects Patients
-2. **Scope detection** — a task touching `api/patients/` only needs Patient-related context
-3. **Skill selection** — files in `components/` need React skills, files in `api/` need backend skills
-4. **Dependency tracking** — the Calendar feature depends on the Auth module
-
-## Structure
-
-The Project Graph lives in `docs/PROJECT_GRAPH.md` and follows this format:
-
-```yaml
-project:
-  name: "DentalCRM"
-  type: crm
-
-modules:
-  patients:
-    description: "Patient management"
-    features:
-      - patient-list
-      - patient-profile
-      - medical-history
-    files:
-      - src/modules/patients/**
-    skills: [react, typescript, postgres]
-    depends_on: [auth]
-
-  appointments:
-    description: "Appointment scheduling"
-    features:
-      - appointment-calendar
-      - appointment-booking
-      - notifications
-    files:
-      - src/modules/appointments/**
-    skills: [react, typescript, postgres]
-    depends_on: [patients, auth]
-
-  auth:
-    description: "Authentication and authorization"
-    features:
-      - login
-      - registration
-      - role-management
-    files:
-      - src/modules/auth/**
-    skills: [security, typescript, jwt]
-    depends_on: []
-```
-
-## How the Context Compiler Uses It
-
-### Task: "Add a reminder notification for appointments"
-
-1. **Locate module**: `appointments`
-2. **Check dependencies**: `appointments` → `patients`, `auth`
-3. **Load relevant files**: `src/modules/appointments/**`, `src/modules/notifications/**`
-4. **Load relevant skills**: `react`, `typescript`, notification patterns
-5. **Load relevant docs**: `ARCHITECTURE.md` (notifications section), `API.md` (endpoints)
-6. **Skip irrelevant**: `DATABASE.md` (no schema change), `UI.md` (if backend-only)
-
-### Task: "Refactor the database schema"
-
-1. **Affected modules**: ALL (schema change is cross-cutting)
-2. **Load**: `DATABASE.md`, `ARCHITECTURE.md`, `PROJECT_GRAPH.md`
-3. **Show impact**: which modules/features are affected by each table change
-4. **Load skills**: `postgres` (or relevant DB skill)
-
-## Automatic Updates
-
-The Project Graph should be updated when:
-
-- New modules are added
-- Features are completed
-- File structure changes significantly
-- Dependencies between modules change
-
-Use `ctx graph` to regenerate the Project Graph from the current codebase.
-
-## Graph Queries
-
-The Context Compiler can answer questions like:
-
-- "What modules does this file belong to?"
-- "What skills are needed for this module?"
-- "What other modules will be affected if I change this?"
-- "Show me the dependency chain from here"
+Use resolve --json to inspect workspaceGraph evidence. There is no ctx graph
+command. Do not promise automatic module-graph updates or a context YAML cache.