codex-workflows 0.6.8 → 0.6.9

package/.agents/skills/ai-development-guide/SKILL.md

@@ -165,7 +165,9 @@ To isolate problems, attempt reproduction with minimal code:
 - Replace external dependencies with mocks
 - Create minimal configuration that reproduces problem
 
-### 4. Debug Log Output
+### 4. Debug Log Output (temporary)
+Add structured debug logs to isolate the issue, then remove them before commit.
+
 ```
 Pattern: Structured logging with context
 {
@@ -204,7 +206,7 @@ Universal quality assurance phases applicable to all languages:
 ### Phase 3: Testing
 1. **Unit Tests**: Run all unit tests
 2. **Integration Tests**: Run integration tests
-3. **Test Coverage**: Measure and verify coverage meets standards
+3. **Test Coverage**: Measure coverage when configured and use it to find gaps
 4. **E2E Tests**: Run end-to-end tests
 
 ### Phase 4: Final Quality Gate [MANDATORY]
@@ -212,7 +214,7 @@ All checks MUST pass before proceeding:
 - Zero static analysis errors
 - Build succeeds
 - All tests pass
-- Coverage meets threshold
+- Coverage threshold passes when the project, task file, work plan, or Design Doc defines one. When no threshold is configured, use coverage output only to identify untested critical paths.
 
 **ENFORCEMENT**: Cannot proceed with ANY quality check failures — fix ALL errors before marking task complete
 

package/.agents/skills/ai-development-guide/references/frontend.md

@@ -75,28 +75,19 @@ console.log('DEBUG:', {
 
 ## Frontend Quality Check Workflow
 
-Use the appropriate run command based on the `packageManager` field in package.json.
+Read `package.json` scripts and run them with the project's package manager from the `packageManager` field. Map the phases below using the script names declared in `package.json`.
 
-### Common Commands
-- `dev` - Development server
-- `build` - Production build
-- `preview` - Preview production build
-- `type-check` - Type check (no emit)
-
-### Quality Check Phases
-**Phase 1-3: Basic Checks**
-- `check` - Linter + formatter (Biome, ESLint, Prettier, etc.)
-- `build` - TypeScript build
-
-**Phase 4-5: Tests and Final Confirmation**
-- `test` - Test execution
-- `test:coverage:fresh` - Coverage measurement (fresh cache)
-- `check:all` - Overall integrated check
+### Phases
+1. **Lint/format** - the project's formatter and linter, such as Biome or ESLint plus Prettier
+2. **Type check** - type check without emit when the project has a dedicated command
+3. **Build** - production build
+4. **Test** - unit and integration tests
+5. **Coverage** - coverage run when configured or when the task added or changed behavior
 
 ### Troubleshooting
-- **Port in use error**: Run `cleanup:processes` script if available
-- **Cache issues**: Run tests with fresh cache option
-- **Dependency errors**: Clean reinstall dependencies
+- **Port already in use**: stop the stale dev, preview, or test process holding the port
+- **Stale cache**: re-run with the project's fresh or clean-cache option
+- **Dependency errors**: clean reinstall dependencies
 
 ## Frontend Technical Decisions
 
@@ -108,6 +99,7 @@ Use the appropriate run command based on the `packageManager` field in package.j
 ### Performance vs Readability
 - Prioritize readability unless clear bottleneck exists
 - Measure before optimizing (use React DevTools Profiler, not guesses)
+- When React Compiler is enabled, routine memoization is automatic. Use manual memoization only for a measured bottleneck or stable reference identity required by third-party APIs or effect dependencies.
 - Document reason with comments when optimizing
 
 ## Frontend Impact Analysis

package/.agents/skills/coding-rules/references/typescript.md

@@ -62,6 +62,11 @@ function isUser(value: unknown): value is User {
 - **Component Hierarchy**: Follow the project's existing component architecture. Use Atoms > Molecules > Organisms > Templates > Pages only when the project adopts Atomic Design.
 - **Co-location**: Place tests, styles, and related files alongside components
 
+**Server/Client Boundary (RSC frameworks only, such as Next.js App Router)**
+- Default to server components for data fetching and rendering. Isolate interactivity behind a `"use client"` boundary at the smallest scope that needs it.
+- Keep browser-only APIs such as `window`, `localStorage`, and event handlers inside client components.
+- Skip this section for client-only SPAs with no server-component runtime.
+
 **State Management Patterns**
 - **Local State**: `useState` for component-specific state
 - **Context API**: For sharing state across component tree (theme, auth, etc.)
@@ -95,19 +100,18 @@ setUsers(users)
 - Type-safe: Always define Props type explicitly
 
 **Environment Variables**
-- **Use build tool's environment variable system**: `process.env` does not work in browsers
-- Centrally manage environment variables through configuration layer
-- Implement proper type safety and default value handling
+- **Use the build tool's env accessor**: read client-side env through the bundler's exposed accessor, such as Vite `import.meta.env` or Next.js/CRA prefixed `process.env`.
+- **Only prefixed vars reach the client**: build tools expose only vars carrying their public prefix. Match the project's bundler, such as Vite `VITE_`, Next.js `NEXT_PUBLIC_`, or CRA `REACT_APP_`.
+- Centrally manage environment variables through a typed configuration layer with defaults.
 
 ```typescript
-// Build tool environment variables (public values only)
+// Client-exposed env must carry the bundler's public prefix, or it is undefined in the browser.
+// Vite:    import.meta.env.VITE_API_URL
+// Next.js: process.env.NEXT_PUBLIC_API_URL
 const config = {
-  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
-  appName: import.meta.env.APP_NAME || 'My App'
+  apiUrl: import.meta.env.VITE_API_URL || 'http://localhost:3000',
+  appName: import.meta.env.VITE_APP_NAME || 'My App'
 }
-
-// Does not work in frontend
-// const apiUrl = process.env.API_URL
 ```
 
 **Security (Client-side Constraints)**
@@ -118,7 +122,7 @@ const config = {
 
 ```typescript
 // Bad: API key exposed in browser
-// const apiKey = import.meta.env.API_KEY
+// const apiKey = import.meta.env.VITE_API_KEY
 // const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
 
 // Good: Backend manages secrets, frontend accesses via proxy
@@ -132,6 +136,7 @@ const response = await fetch('/api/data') // Backend handles API key authenticat
 - Promise Handling: Always use `async/await`
 - Error Handling: Always handle with `try-catch` or Error Boundary
 - Type Definition: Explicitly define return value types (e.g., `Promise<Result>`)
+- Effect race/cleanup: guard `useEffect` data fetches against out-of-order responses and post-unmount state updates with `AbortController`, a mounted/stale flag, or a server-state library such as React Query or SWR.
 
 **Format Rules**
 - Semicolon omission (follow project formatter settings)
@@ -209,10 +214,10 @@ Never include sensitive information (password, token, apiKey, secret, creditCard
 
 ## Performance Optimization
 
-- Component Memoization: Use React.memo for expensive components
+- Automatic memoization: when React Compiler is enabled, rely on it. Use manual `React.memo`, `useMemo`, or `useCallback` only for a profiler-confirmed bottleneck or stable reference identity required by third-party APIs or effect dependencies.
 - State Optimization: Minimize re-renders with proper state structure
 - Lazy Loading: Use React.lazy and Suspense for code splitting
-- Bundle Size: Monitor with the `build` script and keep under 500KB
+- Bundle Size: Monitor with the build script against the project's budget
 
 ## Non-functional Requirements
 

package/.agents/skills/documentation-criteria/references/plan-template.md

@@ -243,7 +243,7 @@ This phase is required for all implementation approaches.
 - [ ] Security review: Verify security considerations from Design Doc are implemented
 - [ ] Quality checks (types, lint, format)
 - [ ] Execute all tests (including integration/E2E from test skeletons, when provided)
-- [ ] Coverage 70%+
+- [ ] Coverage threshold passes when configured
 - [ ] Document updates
 
 ### Quality Assurance

package/.agents/skills/documentation-criteria/references/task-template.md

@@ -17,6 +17,13 @@ Metadata:
 Files to read before starting implementation. Use concrete file paths, optionally with a section/function hint:
 - [e.g., src/orders/checkout.ts (processOrder function)]
 
+## Change Category
+(Include this field only when the task is a bug fix, regression, state-change, or boundary-change. Omit otherwise.)
+
+`Change Category: <one or more of bug-fix, regression, state-change, boundary-change, comma-separated>`
+
+When present, sweep cases sharing the same path, contract, persisted state, or external boundary for the same class of defect during the Red Phase.
+
 ## Binding Decisions
 (Include this section when the work plan's ADR Bindings table covers this task. Omit otherwise.)
 
@@ -34,6 +41,7 @@ Brief observations recorded after reading Investigation Targets:
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
 - [ ] Read all Investigation Targets and update Investigation Notes
+- [ ] (When Change Category is set) Sweep adjacent cases sharing the same path, contract, persisted state, or external boundary for the same class of defect; fold any in-scope residual into failing tests
 - [ ] Review dependency deliverables (if any)
 - [ ] Verify/create contract definitions
 - [ ] Write failing tests

package/.agents/skills/testing/SKILL.md

@@ -52,11 +52,11 @@ For language-specific testing patterns, also read:
 
 ## Quality Requirements [MANDATORY]
 
-### Coverage Standards
+### Coverage
 
-- **Minimum 80% code coverage** for production code
-- Prioritize critical paths and business logic
-- Use coverage as a guide, not a goal
+- Treat coverage as a diagnostic signal for finding untested areas, not a target. Targets get gamed into trivial tests.
+- Concentrate tests on critical paths, business logic, and behavior whose regression would matter.
+- Prioritize meaningful assertions over the coverage number. Any required threshold comes from the project's CI, task file, work plan, or Design Doc.
 
 ### Test Characteristics
 
@@ -279,7 +279,7 @@ Always test:
 ☐ All tests pass
 ☐ No tests skipped or commented
 ☐ No debug code left in tests
-☐ Test coverage meets standards (≥ 80%)
+☐ Coverage threshold passes when the project, task file, work plan, or Design Doc defines one
 ☐ Tests run in reasonable time
 
 ### Zero Tolerance Policy

package/.agents/skills/testing/references/typescript.md

@@ -10,13 +10,9 @@ import { render, screen } from '@testing-library/react'
 import userEvent from '@testing-library/user-event'
 ```
 
-### Coverage Requirements
+### Where to Concentrate Test Rigor
 
-- **Overall minimum**: 60%
-- **Atomic Design projects**: Atoms 70%+, Molecules 65%+, Organisms 60%+
-- **Other component architectures**: Keep 60% as the baseline and raise foundational or highly reused components to 70%+
-- **Custom Hooks**: 65%+
-- **Utils**: 70%+
+Test foundational, high-reuse units the hardest: shared components, custom hooks, utilities, and business rules reused across features carry the widest blast radius. Higher-composition surfaces such as pages and organisms lean more on integration or E2E coverage. Any numeric threshold is the project's CI, task file, work plan, or Design Doc config.
 
 ### Test Types
 

package/.codex/agents/acceptance-test-generator.toml

@@ -265,53 +265,11 @@ A skeleton is committed before its implementation exists, so its committed form
 ### Generation Report
 
 ```json
-{
-  "status": "completed",
-  "feature": "[feature name]",
-  "generatedFiles": {
-    "integration": "[path]/[feature].int.test.[ext]",
-    "fixtureE2e": null,
-    "serviceE2e": null
-  },
-  "budgetUsage": {
-    "integration": "2/3",
-    "fixtureE2e": "0/3",
-    "serviceE2e": "0/2"
-  },
-  "e2eAbsenceReason": {
-    "fixtureE2e": "all_e2e_candidates_below_threshold",
-    "serviceE2e": "no_real_service_dependency"
-  },
-  "boundaryProofGaps": []
-}
+{"status":"completed","feature":"[feature name]","generatedFiles":{"integration":"[path]/[feature].int.test.[ext]","fixtureE2e":null,"serviceE2e":null},"budgetUsage":{"integration":"2/3","fixtureE2e":"0/3","serviceE2e":"0/2"},"e2eAbsenceReason":{"fixtureE2e":"all_e2e_candidates_below_threshold","serviceE2e":"no_real_service_dependency"},"boundaryProofGaps":[]}
 ```
 
 ```json
-{
-  "status": "completed",
-  "feature": "[feature name]",
-  "generatedFiles": {
-    "integration": "[path]/[feature].int.test.[ext]",
-    "fixtureE2e": "[path]/[feature].fixture.e2e.test.[ext]",
-    "serviceE2e": "[path]/[feature].service.e2e.test.[ext]"
-  },
-  "budgetUsage": {
-    "integration": "2/3",
-    "fixtureE2e": "1/3",
-    "serviceE2e": "1/2"
-  },
-  "e2eAbsenceReason": {
-    "fixtureE2e": null,
-    "serviceE2e": null
-  },
-  "boundaryProofGaps": [
-    {
-      "acId": "[AC-XXX]",
-      "boundaryPath": "[branch/state/input/lifecycle/fallback/visibility path]",
-      "reason": "budget_insufficient_for_boundary_proof"
-    }
-  ]
-}
+{"status":"completed","feature":"[feature name]","generatedFiles":{"integration":"[path]/[feature].int.test.[ext]","fixtureE2e":"[path]/[feature].fixture.e2e.test.[ext]","serviceE2e":"[path]/[feature].service.e2e.test.[ext]"},"budgetUsage":{"integration":"2/3","fixtureE2e":"1/3","serviceE2e":"1/2"},"e2eAbsenceReason":{"fixtureE2e":null,"serviceE2e":null},"boundaryProofGaps":[{"acId":"[AC-XXX]","boundaryPath":"[branch/state/input/lifecycle/fallback/visibility path]","reason":"budget_insufficient_for_boundary_proof"}]}
 ```
 
 ## Test Meta Information Assignment

package/.codex/agents/code-reviewer.toml

@@ -78,6 +78,7 @@ For each acceptance criterion extracted in Step 1:
 - For behavior-changing ACs, confirm the evidence covers main and boundary paths. Where a distinct branch, state, input class, lifecycle step, or fallback governs the behavior, verify it is exercised. Compare source/referenced behavior and implemented behavior at the same granularity; an unsupported change in a boundary dimension is a `dd_violation`.
 - Confirm the implementation keeps the core mechanism the AC, Design Doc, or referenced materials require. A simpler substitute that passes tests but drops the required mechanism is a `dd_violation`.
 - For changes to persisted, shared, or externally observable state, identify the publication boundary where the new state becomes observable to another process, component, user, or later step. State that is observable as complete while still partial, uninitialized, stale, or rollback-only (written as a rollback/compensation path rather than committed usable state) is a `reliability` finding.
+- When the reviewed task has `Change Category` set to `bug-fix`, `regression`, `state-change`, or `boundary-change`, check cases sharing its path, contract, persisted state, or external boundary. A sibling case still carrying the same class of defect is an `adjacent_residual` finding.
 
 #### 2-2. Identifier Verification
 For each identifier specification extracted in Step 1:
@@ -134,12 +135,14 @@ Classify each quality finding into one of:
 - `maintainability`: code structure impedes change or comprehension
 - `reliability`: missing safeguards could cause runtime failure
 - `coverage_gap`: acceptance criteria lack meaningful test verification
+- `adjacent_residual`: a case sharing the change's path, contract, persisted state, or external boundary still carries the same class of defect
 
 Each finding MUST include a rationale:
 - `dd_violation`: what the Design Doc says vs what code does
 - `maintainability`: the concrete maintenance or comprehension risk
 - `reliability`: the failure scenario and triggering conditions
 - `coverage_gap`: the untested AC and why coverage matters
+- `adjacent_residual`: which adjacent case shares the path, contract, persisted state, or external boundary and how it still exhibits the defect class
 
 ### 4. Check Architecture Compliance
 Verify against the Design Doc architecture:
@@ -161,63 +164,7 @@ Return the JSON result as the final response. See Output Format for the schema.
 ## Output Format
 
 ```json
-{
-  "complianceRate": "[X]%",
-  "identifierMatchRate": "[X]%",
-  "verdict": "[pass/needs-improvement/needs-redesign]",
-
-  "acceptanceCriteria": [
-    {
-      "item": "[acceptance criteria name]",
-      "status": "fulfilled|partially_fulfilled|unfulfilled",
-      "confidence": "high|medium|low",
-      "location": "[file:line, if implemented]",
-      "evidence": ["[source1: file:line]", "[source2: test file:line]"],
-      "gap": "[what is missing or deviating, if not fully fulfilled]",
-      "suggestion": "[specific fix, if not fully fulfilled]"
-    }
-  ],
-
-  "identifierVerification": [
-    {
-      "identifier": "[identifier name]",
-      "designDocValue": "[value specified in Design Doc]",
-      "codeValue": "[value found in code, or 'not found']",
-      "location": "[file:line]",
-      "confidence": "high|medium|low",
-      "evidence": ["[source1: file:line]", "[source2: config file:line]"],
-      "match": false
-    }
-  ],
-
-  "qualityFindings": [
-    {
-      "category": "dd_violation|maintainability|reliability|coverage_gap",
-      "location": "[filename:function or file:line]",
-      "description": "[specific issue]",
-      "rationale": "[why this matters]",
-      "suggestion": "[specific improvement]"
-    }
-  ],
-
-  "summary": {
-    "acsTotal": 0,
-    "acsFulfilled": 0,
-    "acsPartial": 0,
-    "acsUnfulfilled": 0,
-    "identifiersTotal": 0,
-    "identifiersMatched": 0,
-    "lowConfidenceItems": 0,
-    "findingsByCategory": {
-      "dd_violation": 0,
-      "maintainability": 0,
-      "reliability": 0,
-      "coverage_gap": 0
-    }
-  },
-
-  "nextAction": "[highest priority action needed]"
-}
+{"complianceRate":"[X]%","identifierMatchRate":"[X]%","verdict":"[pass/needs-improvement/needs-redesign]","acceptanceCriteria":[{"item":"[acceptance criteria name]","status":"fulfilled|partially_fulfilled|unfulfilled","confidence":"high|medium|low","location":"[file:line, if implemented]","evidence":["[source1: file:line]","[source2: test file:line]"],"gap":"[what is missing or deviating, if not fully fulfilled]","suggestion":"[specific fix, if not fully fulfilled]"}],"identifierVerification":[{"identifier":"[identifier name]","designDocValue":"[value specified in Design Doc]","codeValue":"[value found in code, or 'not found']","location":"[file:line]","confidence":"high|medium|low","evidence":["[source1: file:line]","[source2: config file:line]"],"match":false}],"qualityFindings":[{"category":"dd_violation|maintainability|reliability|coverage_gap|adjacent_residual","location":"[filename:function or file:line]","description":"[specific issue]","rationale":"[why this matters]","suggestion":"[specific improvement]"}],"summary":{"acsTotal":0,"acsFulfilled":0,"acsPartial":0,"acsUnfulfilled":0,"identifiersTotal":0,"identifiersMatched":0,"lowConfidenceItems":0,"findingsByCategory":{"dd_violation":0,"maintainability":0,"reliability":0,"coverage_gap":0,"adjacent_residual":0}},"nextAction":"[highest priority action needed]"}
 ```
 
 `identifierVerification` MUST include mismatches only. Use `summary.identifiersTotal` and `summary.identifiersMatched` for overall counts.

package/.codex/agents/code-verifier.toml

@@ -158,53 +158,7 @@ Return the JSON result as the final response. See Output Format for the schema.
 ### Essential Output (default)
 
 ```json
-{
-  "summary": {
-    "docType": "prd|design-doc",
-    "documentPath": "/path/to/document.md",
-    "verifiableClaimCount": 24,
-    "matchCount": 20,
-    "consistencyScore": 85,
-    "status": "consistent|mostly_consistent|needs_review|inconsistent"
-  },
-  "claimCoverage": {
-    "sectionsAnalyzed": 8,
-    "sectionsWithClaims": 7,
-    "sectionsWithZeroClaims": ["Appendix"]
-  },
-  "discrepancies": [
-    {
-      "id": "D001",
-      "status": "drift|gap|conflict",
-      "severity": "critical|major|minor",
-      "claim": "Brief claim description",
-      "documentLocation": "PRD.md:45",
-      "codeLocation": "src/auth.ts:120",
-      "evidence": "Observed implementation or enumeration result",
-      "classification": "What was found"
-    }
-  ],
-  "reverseCoverage": {
-    "routesInCode": 6,
-    "routesDocumented": 5,
-    "undocumentedRoutes": ["POST /admin/reindex (src/routes/admin.ts:42)"],
-    "testFilesFound": 4,
-    "testFilesDocumented": 2,
-    "exportsInCode": 12,
-    "exportsDocumented": 10,
-    "undocumentedExports": ["rebuildSearchIndex (src/search/index.ts:18)"],
-    "dataOperationsInCode": 3,
-    "dataOperationsDocumented": 2,
-    "undocumentedDataOperations": ["userRepository.saveUser (src/user/repository.ts:41)"],
-    "testBoundariesSectionPresent": true
-  },
-  "coverage": {
-    "documented": ["Feature areas with documentation"],
-    "undocumented": ["Code features lacking documentation"],
-    "unimplemented": ["Documented specs not yet implemented"]
-  },
-  "limitations": ["What could not be verified and why"]
-}
+{"summary":{"docType":"prd|design-doc","documentPath":"/path/to/document.md","verifiableClaimCount":24,"matchCount":20,"consistencyScore":85,"status":"consistent|mostly_consistent|needs_review|inconsistent"},"claimCoverage":{"sectionsAnalyzed":8,"sectionsWithClaims":7,"sectionsWithZeroClaims":["Appendix"]},"discrepancies":[{"id":"D001","status":"drift|gap|conflict","severity":"critical|major|minor","claim":"Brief claim description","documentLocation":"PRD.md:45","codeLocation":"src/auth.ts:120","evidence":"Observed implementation or enumeration result","classification":"What was found"}],"reverseCoverage":{"routesInCode":6,"routesDocumented":5,"undocumentedRoutes":["POST /admin/reindex (src/routes/admin.ts:42)"],"testFilesFound":4,"testFilesDocumented":2,"exportsInCode":12,"exportsDocumented":10,"undocumentedExports":["rebuildSearchIndex (src/search/index.ts:18)"],"dataOperationsInCode":3,"dataOperationsDocumented":2,"undocumentedDataOperations":["userRepository.saveUser (src/user/repository.ts:41)"],"testBoundariesSectionPresent":true},"coverage":{"documented":["Feature areas with documentation"],"undocumented":["Code features lacking documentation"],"unimplemented":["Documented specs not yet implemented"]},"limitations":["What could not be verified and why"]}
 ```
 
 ### Extended Output (verbose: true)

package/.codex/agents/codebase-analyzer.toml

@@ -129,112 +129,7 @@ Return the JSON result as the final response.
 ## Output Format
 
 ```json
-{
-  "analysisScope": {
-    "filesAnalyzed": ["path/to/file"],
-    "tracedDependencies": ["path/to/dependency"],
-    "categoriesDetected": ["data_layer", "validation"]
-  },
-  "existingElements": [
-    {
-      "category": "function|class|type|interface|component|hook|configuration|constant",
-      "name": "ElementName",
-      "filePath": "path/to/file:line",
-      "signature": "Exact or brief signature",
-      "usedBy": ["path/to/consumer"]
-    }
-  ],
-  "dataModel": {
-    "detected": true,
-    "schemas": [
-      {
-        "name": "table_or_model",
-        "definitionPath": "path/to/file:line",
-        "fields": [
-          {
-            "name": "field_name",
-            "type": "field_type",
-            "constraints": ["NOT NULL", "UNIQUE"]
-          }
-        ],
-        "relationships": ["references other_table via foreign_key"]
-      }
-    ],
-    "accessPatterns": [
-      {
-        "operation": "read|write|aggregate|join|delete",
-        "location": "path/to/file:line",
-        "targetSchema": "table_or_model",
-        "description": "Observed access pattern"
-      }
-    ],
-    "migrationFiles": ["path/to/migration"]
-  },
-  "dataTransformationPipelines": [
-    {
-      "entryPoint": "functionOrMethodName (path/to/file:line)",
-      "steps": [
-        {
-          "order": 1,
-          "method": "functionOrMethodName (path/to/file:line)",
-          "input": "Input data or format at this step",
-          "output": "Output data or format at this step",
-          "externalLookups": ["Config.KEY lookup", "Reference table mapping"],
-          "transformation": "What changed and why it matters"
-        }
-      ],
-      "intermediateFormats": ["Intermediate representation if applicable"],
-      "finalOutput": "Final output shape or observable value"
-    }
-  ],
-  "entryPointInventory": [
-    {
-      "entryPoint": "functionOrMethodName (path/to/file:line)",
-      "classification": "change-relevant|non-relevant",
-      "inputShape": "Input type or shape",
-      "outputShape": "Output type or shape"
-    }
-  ],
-  "constraints": [
-    {
-      "type": "validation|business_rule|configuration|assumption",
-      "description": "Observed constraint",
-      "location": "path/to/file:line",
-      "impact": "Why design should respect it"
-    }
-  ],
-  "qualityAssurance": {
-    "mechanisms": [
-      {
-        "tool": "Tool or check name",
-        "enforces": "What quality aspect it enforces",
-        "configLocation": "path/to/config:line",
-        "coveredFiles": ["affected files or directories covered by this mechanism"],
-        "type": "linter|static_analysis|schema_validator|domain_specific|ci_check"
-      }
-    ],
-    "domainConstraints": [
-      {
-        "constraint": "Description of the domain-specific constraint",
-        "source": "path/to/config-or-ci:line",
-        "affectedFiles": ["files subject to this constraint"]
-      }
-    ]
-  },
-  "focusAreas": [
-    {
-      "area": "Area name",
-      "reason": "Why this area deserves attention",
-      "relatedFiles": ["path/to/file"],
-      "risk": "What could break if the design overlooks it"
-    }
-  ],
-  "testCoverage": {
-    "testedElements": ["element name"],
-    "untestedElements": ["element name"]
-  },
-  "limitations": ["What could not be fully traced and why"]
-}
+{"analysisScope":{"filesAnalyzed":["path/to/file"],"tracedDependencies":["path/to/dependency"],"categoriesDetected":["data_layer","validation"]},"existingElements":[{"category":"function|class|type|interface|component|hook|configuration|constant","name":"ElementName","filePath":"path/to/file:line","signature":"Exact or brief signature","usedBy":["path/to/consumer"]}],"dataModel":{"detected":true,"schemas":[{"name":"table_or_model","definitionPath":"path/to/file:line","fields":[{"name":"field_name","type":"field_type","constraints":["NOT NULL","UNIQUE"]}],"relationships":["references other_table via foreign_key"]}],"accessPatterns":[{"operation":"read|write|aggregate|join|delete","location":"path/to/file:line","targetSchema":"table_or_model","description":"Observed access pattern"}],"migrationFiles":["path/to/migration"]},"dataTransformationPipelines":[{"entryPoint":"functionOrMethodName (path/to/file:line)","steps":[{"order":1,"method":"functionOrMethodName (path/to/file:line)","input":"Input data or format at this step","output":"Output data or format at this step","externalLookups":["Config.KEY lookup","Reference table mapping"],"transformation":"What changed and why it matters"}],"intermediateFormats":["Intermediate representation if applicable"],"finalOutput":"Final output shape or observable value"}],"entryPointInventory":[{"entryPoint":"functionOrMethodName (path/to/file:line)","classification":"change-relevant|non-relevant","inputShape":"Input type or shape","outputShape":"Output type or shape"}],"constraints":[{"type":"validation|business_rule|configuration|assumption","description":"Observed constraint","location":"path/to/file:line","impact":"Why design should respect it"}],"qualityAssurance":{"mechanisms":[{"tool":"Tool or check name","enforces":"What quality aspect it enforces","configLocation":"path/to/config:line","coveredFiles":["affected files or directories covered by this mechanism"],"type":"linter|static_analysis|schema_validator|domain_specific|ci_check"}],"domainConstraints":[{"constraint":"Description of the domain-specific constraint","source":"path/to/config-or-ci:line","affectedFiles":["files subject to this constraint"]}]},"focusAreas":[{"area":"Area name","reason":"Why this area deserves attention","relatedFiles":["path/to/file"],"risk":"What could break if the design overlooks it"}],"testCoverage":{"testedElements":["element name"],"untestedElements":["element name"]},"limitations":["What could not be fully traced and why"]}
 ```
 
 ## Completion Criteria

package/.codex/agents/design-sync.toml

@@ -228,57 +228,7 @@ Severity Assessment:
 ### Output Format [JSON MANDATORY]
 
 ```json
-{
-  "metadata": {
-    "review_type": "design-sync",
-    "source_design": "[source Design Doc path]",
-    "analyzed_docs": 3,
-    "analysis_date": "[execution datetime]"
-  },
-  "summary": {
-    "total_conflicts": 2,
-    "critical": 1,
-    "high": 1,
-    "medium": 0,
-    "confirmed_conflicts": 1,
-    "candidate_conflicts": 1,
-    "sync_status": "CONFLICTS_FOUND"
-  },
-  "confirmed_conflicts": [
-    {
-      "id": "CONFLICT-001",
-      "severity": "critical",
-      "confidence": "high",
-      "match_basis": "exact_string",
-      "type": "Type definition mismatch",
-      "source_file": "[source file]",
-      "source_location": "[section/line]",
-      "source_value": "[content in source file]",
-      "target_file": "[file with conflict]",
-      "target_location": "[section/line]",
-      "target_value": "[conflicting content]",
-      "recommendation": "[Recommend unifying to source file's value]"
-    }
-  ],
-  "candidate_conflicts": [
-    {
-      "id": "CANDIDATE-001",
-      "severity": "high",
-      "confidence": "medium",
-      "match_basis": "same_ac_slot",
-      "type": "Acceptance criteria conflict",
-      "source_file": "[source file]",
-      "source_location": "[section/line]",
-      "source_value": "[content in source file]",
-      "target_file": "[file with conflict]",
-      "target_location": "[section/line]",
-      "target_value": "[conflicting content]",
-      "reason": "[structural evidence linking the items]",
-      "recommendation": "[Recommend reviewing whether these describe the same design slot]"
-    }
-  ],
-  "no_conflicts_docs": ["[filename1]", "[filename2]"]
-}
+{"metadata":{"review_type":"design-sync","source_design":"[source Design Doc path]","analyzed_docs":3,"analysis_date":"[execution datetime]"},"summary":{"total_conflicts":2,"critical":1,"high":1,"medium":0,"confirmed_conflicts":1,"candidate_conflicts":1,"sync_status":"CONFLICTS_FOUND"},"confirmed_conflicts":[{"id":"CONFLICT-001","severity":"critical","confidence":"high","match_basis":"exact_string","type":"Type definition mismatch","source_file":"[source file]","source_location":"[section/line]","source_value":"[content in source file]","target_file":"[file with conflict]","target_location":"[section/line]","target_value":"[conflicting content]","recommendation":"[Recommend unifying to source file's value]"}],"candidate_conflicts":[{"id":"CANDIDATE-001","severity":"high","confidence":"medium","match_basis":"same_ac_slot","type":"Acceptance criteria conflict","source_file":"[source file]","source_location":"[section/line]","source_value":"[content in source file]","target_file":"[file with conflict]","target_location":"[section/line]","target_value":"[conflicting content]","reason":"[structural evidence linking the items]","recommendation":"[Recommend reviewing whether these describe the same design slot]"}],"no_conflicts_docs":["[filename1]","[filename2]"]}
 ```
 
 `total_conflicts` MUST equal `confirmed_conflicts + candidate_conflicts`.
@@ -290,19 +240,7 @@ When no conflicts: `"sync_status": "NO_CONFLICTS"`, `"confirmed_conflicts": []`,
 When fewer than 2 Design Docs exist, return immediately:
 
 ```json
-{
-  "metadata": {
-    "review_type": "design-sync",
-    "source_design": "[provided path]",
-    "analyzed_docs": 1
-  },
-  "summary": {
-    "sync_status": "SKIPPED",
-    "reason": "fewer_than_2_design_docs"
-  },
-  "confirmed_conflicts": [],
-  "candidate_conflicts": []
-}
+{"metadata":{"review_type":"design-sync","source_design":"[provided path]","analyzed_docs":1},"summary":{"sync_status":"SKIPPED","reason":"fewer_than_2_design_docs"},"confirmed_conflicts":[],"candidate_conflicts":[]}
 ```
 
 ENFORCEMENT: sync_status MUST be one of: CONFLICTS_FOUND | NO_CONFLICTS | SKIPPED. These three values are the complete vocabulary.