@rasensio/aidlc 0.4.0 → 0.6.0

package/README.md

@@ -1,299 +0,0 @@
-# AIDLC — AI Development Lifecycle Framework
-
-Structured lifecycle guidance for AI coding agents across platforms. One set of skills, every major AI coding tool.
-
-## Prerequisites
-
-```bash
-# Verify Node.js >= 18
-node --version
-```
-
-```bash
-# Verify npm
-npm --version
-```
-
-## Quick Start
-
-### Install and initialize
-
-```bash
-# Install globally (or use npx without installing)
-npm install -g @rasensio/aidlc
-```
-
-```bash
-# platform: claude-code
-npx @rasensio/aidlc init --platform claude-code
-```
-
-```bash
-# platform: kiro
-npx @rasensio/aidlc init --platform kiro
-```
-
-```bash
-# platform: cursor
-npx @rasensio/aidlc init --platform cursor
-```
-
-```bash
-# platform: windsurf
-npx @rasensio/aidlc init --platform windsurf
-```
-
-```bash
-# platform: codex
-npx @rasensio/aidlc init --platform codex
-```
-
-### Start, check, and continue
-
-```bash
-npx @rasensio/aidlc start
-npx @rasensio/aidlc status
-npx @rasensio/aidlc continue
-```
-
-### Verification
-
-```bash
-npx @rasensio/aidlc status
-```
-
-A successful run outputs lifecycle status and exits with code 0.
-
-## Non-Interactive Setup
-
-The `aidlc setup` command supports fully non-interactive operation for AI agents. All wizard options are available as CLI flags:
-
-```bash
-npx @rasensio/aidlc setup \
-  --project-type existing \
-  --complexity full \
-  --actions git-branch \
-  --platforms claude-code,kiro \
-  --yes
-```
-
-| Flag | Accepted Values | Description |
-|------|----------------|-------------|
-| `--project-type` | `new`, `existing` | Whether this is a new or existing project |
-| `--complexity` | `simple`, `full` | Simple = Micro-Task template; Full = Full Feature template |
-| `--actions` | `git-branch`, `github-issue`, `doc-update` (comma-separated) | Built-in lifecycle actions to enable |
-| `--platforms` | `claude-code`, `kiro`, `cursor`, `windsurf`, `codex` (comma-separated) | Target AI platforms to configure |
-| `--guidance` | `secure-defaults`, `accessibility`, `api-conventions` (comma-separated) | Guidance layers to install |
-| `--yes` | (flag, no value) | Skip all confirmation prompts |
-
-When `--yes` is provided, setup completes without interactive prompts or manual file editing.
-
-## Post-Install: Discovery (Brownfield Projects)
-
-For existing codebases, run discovery to generate project context:
-
-```bash
-npx @rasensio/aidlc discover
-```
-
-This scans the codebase and generates context documents in `.aidlc/context/` covering coding style and architecture. AI agents reference these docs during all lifecycle phases.
-
-Non-interactive mode (overwrites existing docs without prompting):
-
-```bash
-npx @rasensio/aidlc discover --yes
-```
-
-Expected outputs: `.aidlc/context/style-guide.md` and `.aidlc/context/architecture.md`.
-
-## Architecture
-
-### Directory Layout
-
-```
-aidlc/                        # npm package
-├── skills/                   # Universal skill definitions (platform-agnostic)
-├── capabilities/             # Per-platform capability maps (YAML)
-├── templates/                # Built-in workflow templates
-├── guidance/                 # Built-in guidance layers
-├── src/
-│   ├── cli.ts                # CLI entry (commander wiring)
-│   ├── commands/             # One module per CLI verb
-│   ├── core/                 # Lifecycle engine (pure functions)
-│   ├── state/                # State store, atomic writes, transition log
-│   ├── compile/              # Skill parser, adapters, install plans
-│   ├── discover/             # Codebase scanner
-│   ├── events/               # Event bus, action runner
-│   ├── orchestrator/         # Bare-endpoint orchestration
-│   └── setup/                # Setup wizard
-└── test/                     # vitest + fast-check tests
-```
-
-### Key Modules
-
-| Module | Responsibility |
-|--------|---------------|
-| `core/lifecycle.ts` | Pure functions: `evaluateTransition`, `nextStep`, `completionPercent`, `isStalled` |
-| `core/gate.ts` | Phase gate evaluation with exit-code semantics |
-| `state/snapshot-store.ts` | Atomic state persistence (tmp + rename) |
-| `state/transition-log.ts` | Append-only NDJSON transition log |
-| `compile/adapters/` | Platform-specific install plan generators |
-| `compile/merger.ts` | Managed-block merge (preserves surrounding content) |
-| `events/event-bus.ts` | Lifecycle event dispatch, action/hook runner |
-
-### Installed Project Layout
-
-After `aidlc init`, the target project gains:
-
-```
-project/
-├── .aidlc/
-│   ├── config.yaml           # Project configuration (optional)
-│   ├── actions.yaml          # Lifecycle event actions (opt-in)
-│   ├── skills/               # Canonical skill bodies
-│   ├── context/              # style-guide.md, architecture.md
-│   ├── guidance/             # Active guidance layers + index.yaml
-│   ├── templates/            # Custom workflow templates
-│   ├── plugins/              # Extensions
-│   └── state/<instance>/     # Per-instance lifecycle state
-└── (platform configs: .claude/ .kiro/ .cursor/ .windsurf/ AGENTS.md)
-```
-
-## Supported Platforms
-
-| Platform | Config Location | Strategy |
-|----------|----------------|----------|
-| Claude Code | `.claude/skills/aidlc-*/SKILL.md` | Thin activation shims pointing to `.aidlc/skills/` |
-| Kiro | `.kiro/skills/aidlc-*/SKILL.md` + steering | Activation shims + always-included steering file |
-| Cursor | `.cursor/rules/aidlc-*.mdc` | Agent-requested rules with description-based activation |
-| Windsurf | `.windsurf/rules/aidlc-*.md` | Size-constrained pointer shims (under 6K/file) |
-| Codex | `AGENTS.md` (managed block) | Managed delimiter block within existing AGENTS.md |
-
-Each adapter installs canonical skill bodies into `.aidlc/skills/` and generates native platform shims that reference them. Existing non-AIDLC configuration is preserved.
-
-## Lifecycle Phases
-
-| Phase | Purpose |
-|-------|---------|
-| Ideation | Explore and validate ideas, identify alternatives |
-| Requirements | Define acceptance criteria, scope, and constraints |
-| Design | Produce architecture and technical design documents |
-| Implementation | Write code following established conventions |
-| Testing | Validate correctness and coverage |
-| Deployment | Release to target environment |
-| Maintenance | Monitor, patch, and evolve |
-
-Phase applicability depends on the cycle scope: Full (all phases), Standard (Requirements through Deployment), Micro (Implementation + Testing only).
-
-## CLI Commands
-
-| Command | Purpose |
-|---------|---------|
-| `aidlc update` | Update CLI and refresh project skills |
-| `aidlc setup` | Interactive setup or update of project configuration |
-| `aidlc discover` | Scan codebase, generate style and architecture context |
-| `aidlc init --platform <id>` | Install skills for a target AI platform |
-| `aidlc start [template]` | Begin a new lifecycle instance |
-| `aidlc continue [instance]` | Resume the active lifecycle instance |
-| `aidlc status [--json]` | Show progress across active instances |
-| `aidlc review <artifact\|phase>` | Adversarial review of a lifecycle artifact |
-| `aidlc gate <phase>` | CI gate check (exit 0 = complete, exit 1 = incomplete) |
-| `aidlc transition <instance>` | Evaluate gates and advance to the next phase |
-| `aidlc add action "<description>"` | Create a lifecycle action from natural language |
-| `aidlc run [--endpoint <url>]` | Drive a bare LLM endpoint through the lifecycle |
-
-### Dry-Run Mode
-
-Preview what `init` would write without changing files:
-
-```bash
-npx @rasensio/aidlc init --platform claude-code --dry-run
-```
-
-## Configuration
-
-Project configuration lives in `.aidlc/config.yaml`:
-
-```yaml
-version: 1
-defaults: { scope: micro, template: micro-task }
-stalled_threshold_days: 7
-claim_timeout_minutes: 60
-summary_threshold_bytes: 16384
-orchestrator:               # optional, only for bare-endpoint mode
-  endpoint: http://localhost:11434
-  model: qwen2.5-coder
-  api_format: ollama        # ollama | openai
-  auto_advance: false
-  context_budget_tokens: 8000
-```
-
-Without this file, AIDLC defaults to Micro scope (Implementation + Testing only).
-
-## Changelog
-
-### 0.4.0 (2026-08-11)
-
-**Features**
-
-- add monorepo, service, and other project type options
-
-### 0.3.3 (2026-08-11)
-
-**Other**
-
-- add dry-run mode feedback message
-
-### 0.3.2 (2026-08-11)
-
-**Other**
-
-- add /release automation (conventional commits + changelog)
-
-### 0.3.1
-
-**Improved setup wizard UX**
-
-- Every interactive prompt now includes a descriptive message explaining what it controls and why it matters.
-- All options display contextual hints: project types explain the category, complexity shows which phases activate, platforms list the config file they generate, templates show the full phase flow, and scopes enumerate included phases.
-- First-time users can now make informed choices without consulting external docs.
-
-### 0.3.0
-
-**First Activation (brownfield auto-discovery)**
-
-- New skill: `02-first-activation.md` — when AIDLC is installed in an existing project, the AI now automatically scans the codebase on first chat interaction. It detects languages, frameworks, conventions, and directory structure, then asks the user about extra context folders (specs, roadmap, design docs, etc.) before writing context docs to `.aidlc/context/`. No terminal round-trip needed after `aidlc init`.
-
-**`aidlc update` command**
-
-- Self-update: detects which package manager installed AIDLC (npm, pnpm, yarn, bun), checks the npm registry for a newer version, and updates the global CLI.
-- Project refresh: re-runs the install plan for each configured platform, updating skill shims and steering files to match the latest CLI version. Only files whose content changed are rewritten.
-- `--self-only` — update just the CLI, skip project files
-- `--project-only` — refresh project files from the currently installed CLI
-- `--rediscover` — also regenerate `.aidlc/context/` docs (skipped by default to preserve manual edits)
-- `--dry-run` — preview all changes without writing
-
-**Getting-started skill update**
-
-- The getting-started skill now defers to first-activation when `.aidlc/context/` doesn't exist yet, ensuring discovery runs before lifecycle guidance kicks in.
-
-## Contributing
-
-### Build and Test
-
-```bash
-npm install
-npm run build
-npm test
-npm run lint
-```
-
-Tests use vitest (unit + integration) and fast-check (property-based, 14 correctness properties, 100+ iterations each).
-
-### Project Conventions
-
-- TypeScript, ES modules, Node >= 18
-- Pure-function core (no I/O) with I/O pushed to edges
-- Exact-pinned dependencies (no ranges)
-- Property-based tests for core logic, golden-file tests for adapter output
-- Deterministic state serialization (stable key order, block YAML style)

package/capabilities/claude-code.yaml

@@ -1,9 +0,0 @@
-platform: claude-code
-capabilities:
-  plan-mode:
-    phases: [ideation, requirements, design]
-    activation: >-
-      Before producing this phase's artifact, enter plan mode to reason through
-      the problem space, identify constraints, and outline the approach before
-      committing to a structure. Exit plan mode only when you begin writing the
-      artifact.

package/capabilities/codex.yaml

@@ -1,8 +0,0 @@
-platform: codex
-capabilities:
-  code-generation:
-    phases: [implementation, testing]
-    activation: >-
-      Leverage Codex sandboxed execution for this phase. Write implementation
-      code and tests together, using the sandbox to validate that tests pass
-      before proposing the final changeset.

package/capabilities/cursor.yaml

@@ -1,8 +0,0 @@
-platform: cursor
-capabilities:
-  composer:
-    phases: [design, implementation]
-    activation: >-
-      Use Cursor Composer for this phase to coordinate multi-file edits in a
-      single operation. Frame the design or implementation as a Composer prompt
-      describing the desired end state across all affected files.

package/capabilities/kiro.yaml

@@ -1,9 +0,0 @@
-platform: kiro
-capabilities:
-  spec-driven-development:
-    phases: [requirements, design, implementation]
-    activation: >-
-      Use Kiro spec sessions for this phase. Keep spec documents under
-      .kiro/specs/ and let the spec workflow drive requirements, design
-      decisions, and task breakdown. Reference the active spec when producing
-      artifacts so that traceability is maintained.

package/capabilities/windsurf.yaml

@@ -1,8 +0,0 @@
-platform: windsurf
-capabilities:
-  cascade:
-    phases: [implementation]
-    activation: >-
-      Use Windsurf Cascade flows for implementation steps that span multiple
-      files. Keep individual instructions concise due to context-size
-      constraints; reference .aidlc/skills/ for full phase guidance when needed.

package/ci/aidlc-gate.yml

@@ -1,100 +0,0 @@
-# =============================================================================
-# AIDLC Gate Check — GitHub Actions Workflow (sample/reference)
-# =============================================================================
-#
-# This is a SAMPLE workflow demonstrating how to integrate `aidlc gate` into a
-# CI/CD pipeline. Customize it for your project's branching strategy, instance
-# naming, and phase requirements.
-#
-# Exit code semantics:
-#   0 = phase is complete (gate passes, deployment may proceed)
-#   1 = phase is incomplete (gate fails, deployment blocked)
-#
-# The --json flag outputs a structured GateCheckResult object:
-#   { pass, phase, missingArtifacts, unsatisfiedCriteria }
-#
-# Requirements: 9.5
-# =============================================================================
-
-name: AIDLC Gate Check
-
-on:
-  pull_request:
-    branches: [main]
-
-# ---------------------------------------------------------------------------
-# Customization points:
-#
-# 1. AIDLC_INSTANCE — how you derive the lifecycle instance name.
-#    Below we use the PR title, but you could use branch name, a label, etc.
-#
-# 2. AIDLC_PHASE — which phase must be complete before merging.
-#    Common choices: "testing" (pre-merge), "deployment" (pre-deploy).
-#
-# 3. Node version — must be >= 18 (AIDLC prerequisite).
-# ---------------------------------------------------------------------------
-
-jobs:
-  gate:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: '20'
-
-      - run: npm ci
-
-      # -----------------------------------------------------------------------
-      # Run the gate check.
-      # Exit code 0 means the phase is complete; exit code 1 means it is not.
-      # The --json flag produces structured output for downstream steps.
-      # -----------------------------------------------------------------------
-      - name: Check lifecycle gate
-        id: gate
-        run: |
-          set +e
-          OUTPUT=$(npx aidlc gate "$AIDLC_INSTANCE" "$AIDLC_PHASE" --json)
-          EXIT_CODE=$?
-          echo "$OUTPUT"
-          echo "result<<EOF" >> "$GITHUB_OUTPUT"
-          echo "$OUTPUT" >> "$GITHUB_OUTPUT"
-          echo "EOF" >> "$GITHUB_OUTPUT"
-          echo "exit_code=$EXIT_CODE" >> "$GITHUB_OUTPUT"
-          exit $EXIT_CODE
-        env:
-          AIDLC_INSTANCE: ${{ github.event.pull_request.title }}
-          AIDLC_PHASE: implementation
-
-      # -----------------------------------------------------------------------
-      # Optional: post gate results as a PR comment.
-      # Requires the `pull-requests: write` permission on the workflow.
-      # Uncomment and adapt as needed.
-      # -----------------------------------------------------------------------
-      # - name: Comment gate results on PR
-      #   if: always()
-      #   uses: actions/github-script@v7
-      #   with:
-      #     script: |
-      #       const result = JSON.parse(`${{ steps.gate.outputs.result }}`);
-      #       let body;
-      #       if (result.pass) {
-      #         body = `### ✓ AIDLC Gate Passed\n\nPhase **${result.phase}** is complete.`;
-      #       } else {
-      #         const missing = result.missingArtifacts.map(a => `- ${a}`).join('\n');
-      #         const criteria = result.unsatisfiedCriteria.map(c => `- ${c}`).join('\n');
-      #         body = [
-      #           `### ✗ AIDLC Gate Failed`,
-      #           ``,
-      #           `Phase **${result.phase}** is not complete.`,
-      #           missing ? `\n**Missing artifacts:**\n${missing}` : '',
-      #           criteria ? `\n**Unsatisfied criteria:**\n${criteria}` : '',
-      #         ].filter(Boolean).join('\n');
-      #       }
-      #       await github.rest.issues.createComment({
-      #         owner: context.repo.owner,
-      #         repo: context.repo.repo,
-      #         issue_number: context.issue.number,
-      #         body,
-      #       });

package/guidance/accessibility.md

@@ -1,67 +0,0 @@
----
-name: accessibility
-description: Web accessibility guidelines and inclusive design
----
-# Accessibility
-
-Follow these accessibility rules when building user interfaces. All interactive content must be usable by people with diverse abilities, including those using assistive technologies.
-
-## Semantic HTML
-
-- Use semantic elements (`<nav>`, `<main>`, `<article>`, `<section>`, `<header>`, `<footer>`) for page structure.
-- Use heading elements (`<h1>`–`<h6>`) in logical hierarchy; never skip levels for styling.
-- Use `<button>` for actions and `<a>` for navigation; never use `<div>` or `<span>` as interactive elements without proper roles.
-- Use `<label>` elements explicitly associated with form inputs via `for`/`id` pairing.
-- Use lists (`<ul>`, `<ol>`, `<dl>`) for grouped items rather than styled `<div>` sequences.
-
-## ARIA Usage
-
-- Prefer native HTML semantics over ARIA; add ARIA only when no native element provides the required semantics.
-- Use `aria-label` or `aria-labelledby` for interactive elements that lack visible text labels.
-- Set `aria-expanded`, `aria-selected`, `aria-checked` states dynamically to reflect current UI state.
-- Apply `role="alert"` or `aria-live="polite"` for dynamic content that must be announced to screen readers.
-- Never use `aria-hidden="true"` on focusable elements.
-
-## Keyboard Navigation
-
-- All interactive elements must be reachable and operable via keyboard alone (Tab, Shift+Tab, Enter, Space, Arrow keys).
-- Maintain a logical tab order that follows the visual reading flow; avoid positive `tabindex` values.
-- Provide visible focus indicators on all focusable elements; never remove outline without a visible replacement.
-- Implement keyboard shortcuts for complex widgets (modals, dropdowns, tabs) per WAI-ARIA Authoring Practices.
-- Trap focus inside modal dialogs until dismissed; restore focus to the triggering element on close.
-
-## Color and Contrast
-
-- Maintain a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (WCAG AA).
-- Never use color as the sole means of conveying information; pair color with text, icons, or patterns.
-- Verify contrast in both light and dark modes if the application supports theme switching.
-- Ensure focus indicators have at least 3:1 contrast against adjacent colors.
-
-## Images and Media
-
-- Provide meaningful `alt` text for informative images; use `alt=""` for decorative images.
-- Provide captions or transcripts for video and audio content.
-- Avoid auto-playing media; if unavoidable, provide an immediate mechanism to pause or stop.
-- Ensure animated content can be paused and does not flash more than 3 times per second.
-
-## Forms and Errors
-
-- Associate error messages with their input fields using `aria-describedby` or `aria-errormessage`.
-- Display error summaries at the top of forms with links to the offending fields.
-- Do not rely solely on placeholder text as a label; placeholders disappear on input.
-- Group related form controls with `<fieldset>` and `<legend>`.
-- Provide clear instructions before the form and inline help where input format is constrained.
-
-## Responsive and Adaptive Design
-
-- Support zoom up to 200% without loss of content or functionality.
-- Use relative units (rem, em, %) for text and spacing rather than fixed pixels.
-- Ensure touch targets are at least 44x44 CSS pixels for mobile interfaces.
-- Test layouts with different text sizes, languages, and reading directions (LTR/RTL).
-
-## Testing and Verification
-
-- Run automated accessibility scans (axe-core, Lighthouse) in CI and fix all critical/serious issues.
-- Test with at least one screen reader (VoiceOver, NVDA, or JAWS) for major user flows.
-- Validate keyboard-only navigation for all primary workflows.
-- Note: full WCAG conformance requires manual testing with assistive technologies and expert review.

package/guidance/api-conventions.md

@@ -1,124 +0,0 @@
----
-name: api-conventions
-description: REST API naming, error format, and versioning conventions
----
-# API Conventions
-
-Follow these conventions when designing, implementing, or reviewing REST APIs. Consistency across endpoints reduces integration friction and simplifies documentation.
-
-## URL Structure and Naming
-
-- Use lowercase, hyphen-separated path segments: `/user-profiles`, not `/userProfiles` or `/user_profiles`.
-- Use plural nouns for resource collections: `/orders`, `/products`, `/users`.
-- Use resource identifiers as path segments: `/users/{userId}/orders/{orderId}`.
-- Limit nesting to two levels; deeper relationships should use query parameters or links.
-- Use query parameters for filtering, sorting, and pagination: `?status=active&sort=-created_at&page=2`.
-- Avoid verbs in URLs; let HTTP methods convey the action.
-
-## HTTP Methods
-
-- `GET` — Retrieve a resource or collection. Must be safe and idempotent. Never mutate state.
-- `POST` — Create a new resource or trigger a non-idempotent action. Return 201 with Location header for creates.
-- `PUT` — Replace an entire resource. Must be idempotent. Return 200 or 204.
-- `PATCH` — Partially update a resource. Use JSON Merge Patch or JSON Patch content types. Return 200.
-- `DELETE` — Remove a resource. Must be idempotent. Return 204 on success, 404 if already absent.
-- `OPTIONS` — Return allowed methods and CORS headers. Used for preflight requests.
-
-## Status Codes
-
-Use the most specific applicable status code:
-
-| Range | Use for |
-|-------|---------|
-| 200 | Successful retrieval or update |
-| 201 | Resource created (include Location header) |
-| 204 | Success with no response body |
-| 400 | Malformed request (syntax or validation errors) |
-| 401 | Missing or invalid authentication credentials |
-| 403 | Authenticated but insufficient permissions |
-| 404 | Resource not found |
-| 409 | Conflict (e.g., duplicate key, version mismatch) |
-| 422 | Semantically invalid request (valid syntax but business rule violation) |
-| 429 | Rate limit exceeded (include Retry-After header) |
-| 500 | Unexpected server error (never expose internals) |
-
-## Error Response Format
-
-Return a consistent JSON error body for all 4xx and 5xx responses:
-
-```json
-{
-  "error": {
-    "code": "VALIDATION_FAILED",
-    "message": "Human-readable summary of the problem",
-    "details": [
-      {
-        "field": "email",
-        "issue": "Must be a valid email address"
-      }
-    ],
-    "request_id": "req_abc123"
-  }
-}
-```
-
-- `code` — Machine-readable error identifier (UPPER_SNAKE_CASE).
-- `message` — Brief, user-safe description. Never include stack traces or internal paths.
-- `details` — Optional array of field-level errors for validation failures.
-- `request_id` — Correlation identifier for debugging (matches server-side logs).
-
-## Pagination
-
-- Use cursor-based pagination for large or frequently-changing collections.
-- Support limit/offset as a simpler alternative for smaller, stable datasets.
-- Return pagination metadata in the response body:
-
-```json
-{
-  "data": [...],
-  "pagination": {
-    "next_cursor": "eyJpZCI6MTAwfQ",
-    "has_more": true,
-    "total_count": 2340
-  }
-}
-```
-
-- Include `total_count` only when it can be computed efficiently.
-
-## Versioning
-
-- Use URL prefix versioning for major breaking changes: `/v1/users`, `/v2/users`.
-- Increment the version number only on backward-incompatible changes.
-- Support the previous major version for at least 6 months after a new version ships.
-- Treat additive changes (new optional fields, new endpoints) as backward-compatible.
-- Document deprecation timelines in the Sunset response header and changelog.
-
-## Request and Response Conventions
-
-- Use `snake_case` for JSON field names throughout request and response bodies.
-- Represent timestamps in ISO 8601 format with UTC timezone: `2025-06-15T10:30:00Z`.
-- Use envelope format for collections: `{ "data": [...], "pagination": {...} }`.
-- Return the full created or updated resource in response to POST, PUT, and PATCH.
-- Accept and return `Content-Type: application/json` by default.
-- Support `Accept` header negotiation where multiple formats are available.
-
-## Rate Limiting and Throttling
-
-- Enforce rate limits per client or API key.
-- Return `429 Too Many Requests` with a `Retry-After` header (seconds until next allowed request).
-- Include rate limit headers on every response: `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`.
-
-## CORS and Security Headers
-
-- Configure CORS to allow only trusted origins; avoid wildcard `*` in production.
-- Return appropriate CORS headers: `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers`.
-- Set `Cache-Control: no-store` on responses containing sensitive data.
-- Include `X-Content-Type-Options: nosniff` and `X-Request-Id` on all responses.
-
-## Documentation and Discoverability
-
-- Provide an OpenAPI 3.x specification for every public API.
-- Include request/response examples for each endpoint.
-- Document authentication requirements, rate limits, and error codes.
-- Use consistent terminology across endpoint descriptions.

package/guidance/index.yaml

@@ -1,7 +0,0 @@
-layers:
-  - name: secure-defaults
-    file: secure-defaults.md
-  - name: accessibility
-    file: accessibility.md
-  - name: api-conventions
-    file: api-conventions.md