contextos-agents 2.0.0 → 2.1.0

package/.agents/compiled/registry.v2.sha256

@@ -1 +1 @@
-sha256:c15f3691d9ed833630152b65959fdef465d88a7cf5bb27d44a086621e20c89c1  registry.v2.json
+sha256:938c5051454535087e03f26af35c434cf194f414d2ec8044b4ae754e8524cf37  registry.v2.json

package/.agents/core/skills/context-os/SKILL.md

@@ -8,11 +8,11 @@ description: >-
 
 ## Overview
 
-Deterministic context compiler and policy engine for AI coding agents. Standardizes software engineering workflows across requirements, architecture, atomic task planning, implementation, verification, and release.
+Deterministic context compiler and policy engine for AI coding agents. Governs repository policy configuration, skill dependency graphs, profile management, and multi-agent configuration export.
 
 ## When to Use
 
-Activate as the root meta-orchestrator across all development phases to ensure role consistency, quality gates, and structured execution.
+Activate when managing project configuration, resolving skill dependencies, compiling rules for editors, or defining repository-level agent standards. (For task-specific file and context budgeting, use `context-manager`).
 
 ## Rules & Patterns
 
@@ -46,10 +46,10 @@ intent:
 For each required layer, load the skill graph:
 
 1. Read `skill.yaml` from each relevant skill directory
-2. Resolve `requires` — load mandatory dependencies
-3. Check `conflicts` — ensure no incompatible skills are loaded
-4. Apply `optional` — suggest but don't force
-5. Respect project profile (if set) — apply rules from `profiles/`
+2. Resolve `requires` - load mandatory dependencies
+3. Check `conflicts` - ensure no incompatible skills are loaded
+4. Apply `optional` - suggest but don't force
+5. Respect project profile (if set) - apply rules from `profiles/`
 
 **Dependency resolution example:**
 
@@ -67,48 +67,45 @@ Suggested: [tailwind, prisma, next-auth]
 
 Assemble context from three levels:
 
-**Level 1 — Vision (always available):**
+**Level 1 - Vision (always available):**
 
-- `docs/PRD.md` — what are we building
-- `docs/ROADMAP.md` — where are we going
-- `docs/PROJECT_GRAPH.md` — project structure
+- `docs/PRD.md` - what are we building
+- `docs/ROADMAP.md` - where are we going
+- `docs/PROJECT_GRAPH.md` - project structure
+- `docs/API.md` - API specification (optional, when backend API layer is present)
+- `docs/UI.md` - UI/UX specification (optional, when UI layer is present)
 
-**Level 2 — Architecture (load when needed):**
+**Level 2 - Architecture (load when needed):**
 
-- `docs/ARCHITECTURE.md` — system design
-- `docs/DATABASE.md` — data model
-- `docs/API.md` — API contracts
-- `docs/decisions/` — prior decisions
+- `docs/ARCHITECTURE.md` - system design and boundaries
+- `docs/decisions/` - architecture decision records (ADRs)
+- `docs/PRODUCT_BOUNDARIES.md` - maturity boundaries and non-promises
+- `references/context-rules.md` - dynamic context selection and compilation rules
 
-**Level 3 — Development (load per task):**
+**Level 3 - Task-Specific Context (load per task):**
 
-- Relevant skill `.md` files
-- `docs/UI.md` — for frontend tasks
-- `docs/TASKS.md` — current sprint
+- Relevant skill documents from `.agents/skills/`
+- Target code and test files within planned blast radius
 
-**Context Filtering Rules:**
-See `references/context-rules.md` for the full mapping of task types to required documents.
+### Stage 4: Focused Context Selection
 
-### Stage 4: Prompt Optimization
+Before sending context to the AI coding assistant:
 
-Before sending to the AI agent:
+1. Select only skills relevant to the task domain and touched files
+2. Prioritize: task goal > architectural constraints > project conventions
+3. Include active Decision Records that affect the target component
+4. Enforce quality guardrails and verification criteria
 
-1. Remove sections not relevant to the current task
-2. Prioritize: current task context > architecture > vision
-3. Include recent Decision Records that affect the current task
-4. Add coding rules from the loaded skills
-
-## Commands
+## Core CLI Commands
 
 | Command | Action |
 | --- | --- |
-| `ctx init` | Analyze project idea, generate all docs |
-| `ctx plan` | Generate development plan from PRD |
-| `ctx compile` | Compile context for a specific task |
-| `ctx update` | Update changed documents |
-| `ctx graph` | Show/update Project Graph |
-| `ctx doctor` | Validate skill dependencies, check for conflicts |
-| `ctx explain` | Explain why specific context was loaded |
+| `contextos init` | Initialize `.agents/` folder and bootstrap profiles |
+| `contextos export <agent>` | Compile skills for target agent (`gemini`, `claude`, `cursor`, `copilot`, `aider`, `zed`, `all`) |
+| `contextos resolve "<task>"` | Dynamically resolve relevant skills, rules, and risk level for task |
+| `contextos validate` | Validate skill schemas, dependencies, and detect configuration drift |
+| `contextos doctor` | Pre-flight diagnostics for skills, profiles, and compiler synchronization |
+| `contextos watch` | Background file watcher for continuous auto-compilation |
 
 ## Project Initialization Flow
 
@@ -126,7 +123,7 @@ When user says something like "Сделай CRM для стоматологии"
 3. **Select profile** (startup/enterprise/mvp/hackathon)
 4. **Resolve skills** (Stage 2)
 5. **Generate all documents** using `generators/` skill
-6. **Create Project Graph** — the master map of modules → features → tasks → files → skills
+6. **Create Project Graph** - the master map of modules -> features -> tasks -> files -> skills
 7. **Output agent config** using `adapters/` skill
 
 ## Skill Discovery

package/.agents/core/skills/engineering-workflow/SKILL.md

@@ -45,7 +45,7 @@ Inspired by [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills
 
 ---
 
-### Phase 1: DEFINE — /spec
+### Phase 1: DEFINE - /spec
 
 **Auto-activates → `[ROLE: Product Manager]`**
 
@@ -79,8 +79,8 @@ Before writing the spec, if there is ambiguity, high blast radius, or multiple a
 ### Technical Approach
 [Read the relevant code. Understand what changes where.]
 Files affected:
-- `src/X.js` — [what changes]
-- `src/Y.js` — [what changes]
+- `src/X.js` - [what changes]
+- `src/Y.js` - [what changes]
 
 ### Acceptance Criteria
 - [ ] Given [context], when [action], then [result]
@@ -93,7 +93,7 @@ Files affected:
 
 ---
 
-### Phase 2: PLAN — /plan
+### Phase 2: PLAN - /plan
 
 **Auto-activates → `[ROLE: Architect]`**
 
@@ -111,7 +111,7 @@ Organize tasks as **Thin Vertical Slices** rather than horizontal layers:
 - Each task must be **completable in < 2 hours** of focused work.
 - Each task must be **independently testable**.
 - Tasks must be **ordered by dependency** (blocking tasks first).
-- Each task gets a **test requirement** — no task without a test.
+- Each task gets a **test requirement** - no task without a test.
 
 #### Plan Template
 
@@ -136,13 +136,13 @@ Organize tasks as **Thin Vertical Slices** rather than horizontal layers:
 - [Risk 1]: [Mitigation]
 - [Risk 2]: [Mitigation]
 
-### STOP — Awaiting Approval
+### STOP - Awaiting Approval
 Do not proceed to BUILD until this plan is approved.
 ```
 
 ---
 
-### Phase 3: BUILD — /build
+### Phase 3: BUILD - /build
 
 **Auto-activates → `[ROLE: Senior Developer]`**
 
@@ -150,12 +150,12 @@ Implement one task at a time. Commit after each task.
 
 #### Build Rules
 
-1. **One task per commit** — atomic, descriptive commit messages.
-2. **Write the test FIRST** (TDD — red-green-refactor).
-3. **No dead code** — if it's not tested, it's not shipped.
-4. **No TODOs in committed code** — resolve or create a tracked issue.
-5. **Read before writing** — understand the surrounding code before changing it.
-6. **Limit the blast radius** — modify ONLY the files explicitly listed in the current task's plan. Do NOT rewrite adjacent components, hooks, or utilities unless strictly required AND approved.
+1. **One task per commit** - atomic, descriptive commit messages.
+2. **Write the test FIRST** (TDD - red-green-refactor).
+3. **No dead code** - if it's not tested, it's not shipped.
+4. **No TODOs in committed code** - resolve or create a tracked issue.
+5. **Read before writing** - understand the surrounding code before changing it.
+6. **Limit the blast radius** - modify ONLY the files explicitly listed in the current task's plan. Do NOT rewrite adjacent components, hooks, or utilities unless strictly required AND approved.
 
 #### Commit Message Format
 
@@ -172,7 +172,7 @@ Types: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`
 
 ---
 
-### Phase 4: VERIFY — /test
+### Phase 4: VERIFY - /test
 
 **Auto-activates → `[ROLE: QA Lead]`**
 
@@ -193,7 +193,7 @@ Tests are proof, not an afterthought.
 
 For complex React components, prioritize testing _user behavior_ over internal state:
 
-- Use **React Testing Library** (`userEvent`, `screen.getByRole`) — test what the user sees.
+- Use **React Testing Library** (`userEvent`, `screen.getByRole`) - test what the user sees.
 - Use **Playwright** for critical user flows (login, checkout, form submit).
 - Do NOT test implementation details (internal state, private methods, component structure).
 - Focus on: "When user clicks X, does Y appear?" not "Does `useState` hold the right value?"
@@ -220,7 +220,7 @@ Before moving to Review, verify:
 
 ---
 
-### Phase 5: REVIEW — /review
+### Phase 5: REVIEW - /review
 
 **Auto-activates → `[ROLE: Staff Engineer]` + `[ROLE: Senior Designer]` for UI tasks**
 
@@ -240,7 +240,7 @@ Inspired by [obra/superpowers](https://github.com/obra/superpowers):
 
 ---
 
-### Phase 5.5: SIMPLIFY — /simplify
+### Phase 5.5: SIMPLIFY - /simplify
 
 **Auto-activates → `[ROLE: Staff Engineer]` (Ponytail Mindset)**
 
@@ -253,7 +253,7 @@ Before merging, ruthlessly simplify:
 
 ---
 
-### Phase 6: SHIP — /ship
+### Phase 6: SHIP - /ship
 
 **Auto-activates → `[ROLE: Release Engineer]`**
 
@@ -267,8 +267,7 @@ Only ship when all gates are green.
 - [ ] Docs updated (README, API docs, changelogs)
 - [ ] Breaking changes documented
 - [ ] Rollback plan exists
-- [ ] Vercel Preview Deployment is successful and manually verified
-- [ ] Core Web Vitals pass in preview (LCP < 2.5s, CLS < 0.1, INP < 200ms)
+- [ ] Preview / staging deployment verified (if applicable, e.g. Vercel Preview and Core Web Vitals for frontend deployments)
 
 #### Operational Self-Improvement
 
@@ -311,6 +310,7 @@ export async function POST(req) {
 - [ ] Implementation plan broken down into vertical tasks < 2 hours each.
 - [ ] Tests written before implementation (TDD/BDD).
 - [ ] Code reviewed against correctness, security, performance, and design gates.
+- [ ] Staged security and quality check passes (`contextos scan --staged --enforce`).
 - [ ] Simplification ladder executed before shipping.
 
 ---
@@ -337,7 +337,7 @@ export async function POST(req) {
 
 When completing a task or workflow, you must explicitly report your final status as the last part of your output:
 
-- **DONE** — completed with evidence.
-- **DONE_WITH_CONCERNS** — completed, but list concerns.
-- **BLOCKED** — cannot proceed; state blocker and what was tried.
-- **NEEDS_CONTEXT** — missing info; state exactly what is needed.
+- **DONE** - completed with evidence.
+- **DONE_WITH_CONCERNS** - completed, but list concerns.
+- **BLOCKED** - cannot proceed; state blocker and what was tried.
+- **NEEDS_CONTEXT** - missing info; state exactly what is needed.

package/.agents/core/skills/gemini-precision/EXAMPLES.md

@@ -0,0 +1,72 @@
+# gemini-precision Examples - Anti-patterns vs ContextOS Standard
+
+## Example 1: Read-Before-Write Invariant (Zero Assumptions)
+
+### Anti-pattern: Hallucinated Import and Signature
+
+```typescript
+// BAD: Assuming the module exists and export is a default function
+import hashPassword from 'src/utils/crypto';
+const hash = hashPassword(password);
+```
+
+### Best practice: ContextOS Standard (Inspected Active Codebase First)
+
+```typescript
+// GOOD: Inspected src/lib/auth.ts via view_file before writing code
+import { hashSecret, ARGON2_CONFIG } from '../lib/auth.js';
+const hash = await hashSecret(password, ARGON2_CONFIG);
+```
+
+---
+
+## Example 2: Zero-Placeholder Invariant (Complete Code Only)
+
+### Anti-pattern: Lazy Stubs and Ellipsis Comments
+
+```typescript
+// BAD: Emitting incomplete code with TODOs and ellipsis
+export function processTransaction(tx: Transaction) {
+  // TODO: validate transaction balance
+  // ... rest of implementation stays here ...
+  return { status: 'ok' };
+}
+```
+
+### Best practice: ContextOS Standard (100% Drop-in Compilable)
+
+```typescript
+// GOOD: Fully implemented logic with complete error handling
+export function processTransaction(tx: Transaction): TransactionResult {
+  if (!tx.amount || tx.amount <= 0) {
+    throw new ValidationError('Transaction amount must be positive');
+  }
+  if (tx.senderBalance < tx.amount) {
+    throw new InsufficientFundsError(tx.senderId, tx.amount);
+  }
+  return {
+    status: 'ok',
+    transactionId: tx.id,
+    newBalance: tx.senderBalance - tx.amount,
+  };
+}
+```
+
+---
+
+## Example 3: Mandatory Proof-of-Work Invariant
+
+### Anti-pattern: Claiming Task Complete Without Evidence
+
+```text
+BAD: "I have updated the authentication handler. The code looks correct and is ready to merge."
+```
+
+### Best practice: ContextOS Standard (Verified with Automated Gates)
+
+```bash
+# GOOD: Run test suite, staged scanner, and consistency checks
+npm test
+contextos scan --staged --enforce
+node .agents/ctx.js validate
+```

package/.agents/core/skills/gemini-precision/SKILL.md

@@ -51,6 +51,7 @@ Activate whenever:
   1. Run the project validator or compiler (`node .agents/ctx.js validate`, `tsc --noEmit`, etc.).
   2. Run unit and integration tests (`npm test`, `pytest`, etc.).
   3. Run linter and formatting checks (`npm run lint:md`, `eslint`, etc.).
+  4. Run staged security and quality scanner (`contextos scan --staged --enforce`).
 - If a test or validation fails, do not guess: read the exact error trace, fix the root cause, and re-run until green.
 
 ### 4. Surgical Blast Radius Containment
@@ -86,7 +87,7 @@ Activate whenever:
 **Eliminate the "black box" by narrating technical decisions.**
 
 - Avoid executing long, silent chains of tool calls without user visibility.
-- Provide a concise 1–2 sentence transparent status update before key operations:
+- Provide a concise 1-2 sentence transparent status update before key operations:
   - State what was inspected or verified from the code.
   - State the architectural decision made and the immediate next action.
 - Keep narration crisp and actionable without excessive verbosity.

package/.agents/core/skills/gemini-precision/TROUBLESHOOTING.md

@@ -0,0 +1,25 @@
+# gemini-precision Troubleshooting & Common Failure Modes
+
+## 1. Test Failure Investigation (No Guesswork)
+
+- **Symptom**: Test fails during `npm test` after code modifications.
+- **Root Cause**: Trying to patch the code without reading the exact assertion diff.
+- **Fix**: Never guess the fix. View the test file line where assertion failed, inspect expected vs actual output, and resolve the root discrepancy.
+
+## 2. Accidental Staged Secrets or Placeholders
+
+- **Symptom**: `contextos scan --staged --enforce` fails with exit code 1.
+- **Root Cause**: Committed temporary `.env` file or left an unfinished `// TODO: implement later` stub in added lines.
+- **Fix**: Remove or redact the secret before committing. Fully implement the logic or replace the placeholder with an explicit tracked issue rather than committed code stubs.
+
+## 3. Scope Creep and Excessive Blast Radius
+
+- **Symptom**: Unrelated files reformatted or imports reordered across the repository.
+- **Root Cause**: Full-file rewrite instead of targeted surgical replacement.
+- **Fix**: Use targeted chunks that touch only the lines specified in the task plan. Avoid modifying unrelated styling or formatting.
+
+## 4. Forbidden Long Dashes
+
+- **Symptom**: Linter or compliance check flags unicode dashes in text.
+- **Root Cause**: Using typography dashes (`\u2014` or `\u2013`) instead of standard ASCII hyphens.
+- **Fix**: Replace all em-dashes and en-dashes with standard ASCII hyphens (` - `) or appropriate punctuation (parentheses, commas, colons).

package/.agents/core/skills/gemini-precision/skill.yaml

@@ -4,5 +4,7 @@ type: instruction-only
 description: High-precision engineering and execution guardrails optimized for Google Gemini models. Enforces zero-assumption file inspection, complete non-lazy implementations, surgical blast-radius containment, and mandatory proof-of-work execution.
 version: 1.0.0
 resources:
+  - EXAMPLES.md
   - SKILL.md
+  - TROUBLESHOOTING.md
   - VALIDATION.json

package/.agents/core/skills/gstack-roles/SKILL.md

@@ -17,7 +17,7 @@ Activate on every task to declare explicit specialist role and mindset before be
 
 ## Rules & Patterns
 
-Inspired by [Garry Tan's gstack](https://github.com/garrytan/gstack) — shipping 810× more logical code than a solo dev in 2013.
+Inspired by [Garry Tan's gstack](https://github.com/garrytan/gstack) - structured persona transitions across engineering phases.
 
 ## Core Principle
 
@@ -25,13 +25,14 @@ Inspired by [Garry Tan's gstack](https://github.com/garrytan/gstack) — shippin
 
 ## Role Identification Protocol
 
-At the start of each task or major phase switch, declare your role:
+At the start of each task or major phase switch, declare your role using the ContextOS standard format:
 
-```
-[ROLE: <Role Name>] — <One-line description of your mandate for this task>
+```text
+[DOMAIN: <Domain>] [PHASE: <Phase>] [ROLE: <Role Name>]
+Skills loaded: <skill-1>, <skill-2>
 ```
 
-> **Anti-Spam Invariant**: Declare this role **strictly once per phase**. Never prefix intermediate tool calls, file operations, or step updates with role tags.
+> **Anti-Spam Invariant**: Declare this role header **strictly once per phase**. Never prefix intermediate tool calls, file operations, or step updates with role tags.
 
 Then execute ONLY within the constraints of that role.
 
@@ -110,7 +111,7 @@ THINK          PLAN           BUILD          REVIEW         TEST           SHIP
 2. **One role at a time.** Don't mix QA and implementation in the same response.
 3. **Declare before acting.** Always state `[ROLE: X]` before switching modes.
 4. **Escalate correctly.** If a QA finds an architectural problem → escalate to Architect role.
-5. **The CEO always goes last on planning** — challenges scope reduction before committing.
+5. **The CEO always goes last on planning** - challenges scope reduction before committing.
 
 ## Example Usage
 

package/.agents/core/skills/security/SKILL.md

@@ -32,7 +32,7 @@ Activate whenever writing authentication, authorization, session management, dat
 
 #### 1. Injection (SQL, NoSQL, Command)
 
-- Always use parameterized queries — never concatenate user input into SQL or shell commands.
+- Always use parameterized queries - never concatenate user input into SQL or shell commands.
 - Use ORMs (Prisma, Drizzle, SQLAlchemy) with strict schema validation.
 - Validate and sanitize all user input before processing.
 
@@ -81,14 +81,20 @@ When building AI workflows, tools, or MCP servers:
    - Never allow untrusted content to override system instructions or tool execution permissions.
 2. **Tool Execution Boundaries**:
    - Destructive operations (database drops, file deletions, payment triggers) MUST require explicit user confirmation.
-   - Restrict file system tools to the workspace root — block directory traversal (`../`).
+   - Restrict file system tools to the workspace root - block directory traversal (`../`).
 3. **Secret Masking & Output Sanitization**:
    - Scrub API keys (`sk-...`, `Bearer ...`), tokens, and credentials before writing to agent logs or step summaries.
+4. **Sandbox Execution & Write Isolation (Supply-Chain Defense)**:
+   - Target code is inspected strictly read-only; never execute target-controlled builds or tests with write access to the repository root.
+   - Restrict process write boundaries strictly to an isolated temporary `scratch/` directory.
+   - Enforce zero outbound external network access during security audits to prevent secret exfiltration via malicious scripts or dependencies.
+   - Promote verified non-secret results to retained `artifacts/` only via trusted parent-side inspection code.
 
 ---
 
 ## Code Examples
 
+
 ### Timing-Safe Secret Verification
 
 ```javascript
@@ -104,28 +110,50 @@ export function verifyWebhookSignature(payload, signature, secret) {
 }
 ```
 
-### Safe SSRF Prevention Wrapper
+### SSRF Prevention Requirements (OWASP Compliant)
 
-```typescript
-import dns from 'node:dns/promises';
+Per [OWASP SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html), naive application-level DNS pre-checks followed by standard `fetch(url)` are fundamentally flawed due to DNS rebinding (TOCTOU) and unvalidated HTTP 3xx redirects.
+
+#### Mandatory Architectural Controls
 
-export async function validateSafeUrl(urlString: string): Promise<URL> {
+1. **Network-Layer Defense (Primary)**: For user-supplied arbitrary webhooks or URLs, route all outbound traffic through an isolated egress forward proxy (e.g., Smokescreen, Envoy, Squid) configured with firewall-level IP filters blocking RFC 1918, RFC 6598, link-local (`169.254.169.254`), loopback, and IPv6 local addresses at the socket handshake level.
+2. **Positive Destination Allowlist**: If fetching from known external partners, validate destination hostname against a strict positive allowlist.
+3. **Disable Automatic Redirects**: Always set `redirect: 'error'` or `'manual'`. Never follow HTTP redirects automatically without re-validating the target URL against allowlist rules.
+4. **Protocol & Credential Restrictions**: Enforce `https:` exclusively; reject embedded credentials (`user:pass@host`) and non-standard ports.
+
+```typescript
+/**
+ * Verified Allowlist-based HTTP Client (OWASP SSRF Prevention)
+ * Enforces HTTPS, strict destination allowlist, and rejects HTTP redirects.
+ */
+export async function fetchFromAllowlist(
+  urlString: string,
+  allowedHostnames: ReadonlySet<string>,
+  options: RequestInit = {}
+): Promise<Response> {
   const parsed = new URL(urlString);
+
+  // 1. Enforce HTTPS only
   if (parsed.protocol !== 'https:') {
-    throw new Error('Only HTTPS protocol is permitted');
+    throw new Error(`SSRF blocked: protocol "${parsed.protocol}" is not permitted; HTTPS required`);
+  }
+
+  // 2. Reject credentials in URL
+  if (parsed.username || parsed.password) {
+    throw new Error('SSRF blocked: URL credentials (user:password@host) are prohibited');
   }
 
-  const { address } = await dns.lookup(parsed.hostname);
-  if (
-    address.startsWith('127.') ||
-    address.startsWith('10.') ||
-    address.startsWith('192.168.') ||
-    address === '169.254.169.254'
-  ) {
-    throw new Error('Access to private/metadata IP addresses is blocked');
+  // 3. Strict positive destination allowlist (prevents internal network probing)
+  const normalizedHost = parsed.hostname.toLowerCase();
+  if (!allowedHostnames.has(normalizedHost)) {
+    throw new Error(`SSRF blocked: destination host "${normalizedHost}" is not in the approved allowlist`);
   }
 
-  return parsed;
+  // 4. Disable automatic redirects to prevent redirection to private IPs or metadata endpoints
+  return fetch(urlString, {
+    ...options,
+    redirect: 'error'
+  });
 }
 ```
 

package/.agents/core/skills/security/skill.yaml

@@ -12,7 +12,6 @@ resources:
   - SKILL.md
   - TROUBLESHOOTING.md
   - VALIDATION.json
-  - security.md
 rules:
   - id: SEC-001
     level: must

package/.agents/ctx.js

@@ -97,25 +97,31 @@ if (command === 'export') {
   const pureCompiler = require('./adapters/pure-compiler.js');
   const driftDetector = require('./adapters/drift-detector.js');
 
+  const isCheck = args.includes('--check');
+  const isDiff = args.includes('--diff');
+  const isDryRun = args.includes('--dry-run');
+  const asJson = args.includes('--json');
+
   const profileFlagIdx = args.indexOf('--profile');
   let overrideProfile = null;
   if (profileFlagIdx !== -1 && args[profileFlagIdx + 1]) {
     const profiles = require('./profiles.js');
     overrideProfile = args[profileFlagIdx + 1];
     try {
-      profiles.applyProfile(overrideProfile);
-      console.log(`[PROFILE] Applied profile '${overrideProfile}' for this export.\n`);
+      const prof = profiles.getProfile(overrideProfile, process.cwd());
+      if (!prof) {
+        throw new Error(`Profile '${overrideProfile}' not found`);
+      }
+      if (!isCheck && !isDryRun && !isDiff) {
+        profiles.applyProfile(overrideProfile);
+        console.log(`[PROFILE] Applied profile '${overrideProfile}' for this export.\n`);
+      }
     } catch (err) {
       console.error(`[ERROR] ${err.message}`);
-      process.exit(1);
+      process.exit(2);
     }
   }
 
-  const isCheck = args.includes('--check');
-  const isDiff = args.includes('--diff');
-  const isDryRun = args.includes('--dry-run');
-  const asJson = args.includes('--json');
-
   const rawTarget = args[1] && !args[1].startsWith('--') ? args[1] : 'all';
 
   // 1. Drift Check Mode (--check)
@@ -125,7 +131,7 @@ if (command === 'export') {
       console.log(JSON.stringify(drift, null, 2));
     } else {
       console.log('\nContextOS — Adapter Output Drift Check\n');
-      if (!drift.hasDrift) {
+      if (!drift.hasDrift && !drift.hasError) {
         console.log(`✓ No adapter drift detected. All ${drift.projectedCount} output artifacts are synchronized.`);
       } else {
         console.log(`! Drift detected (${drift.totalFindings} finding(s)):\n`);
@@ -146,7 +152,7 @@ if (command === 'export') {
         console.log('\nRun: node .agents/ctx.js export all    to synchronize outputs with source skills.\n');
       }
     }
-    process.exit(drift.hasDrift ? 1 : 0);
+    process.exit(drift.code !== undefined ? drift.code : (drift.hasDrift ? 1 : 0));
   }
 
   // 2. Diff Preview Mode (--diff)