@devtrack-solution/codesdd 1.2.2 → 1.2.3

package/.sdd/skills/curated/api-clean-flask-langgraph/SKILL.md

@@ -327,21 +327,21 @@ class CreateAppointmentUseCase:
 
 ---
 
-## OpenSDD decision-support mode (never runtime dependency)
+## CodeSDD decision-support mode (never runtime dependency)
 
-Use this mode when the target repository already has a `.sdd/` root and the team is using OpenSDD planning artifacts.
+Use this mode when the target repository already has a `.sdd/` root and the team is using CodeSDD planning artifacts.
 
-The goal is to improve architecture decisions with explicit traceability, not to add OpenSDD runtime dependencies to generated Flask code.
+The goal is to improve architecture decisions with explicit traceability, not to add CodeSDD runtime dependencies to generated Flask code.
 
-### Mandatory OpenSDD workflow for architecture decisions
+### Mandatory CodeSDD workflow for architecture decisions
 
-1. Run `opensdd sdd onboard system` before broad design work.
-2. Run `opensdd sdd next` and select active or ready work.
-3. Run `opensdd sdd context <FEAT-ID>` before drafting architecture changes.
+1. Run `codesdd sdd onboard system` before broad design work.
+2. Run `codesdd sdd next` and select active or ready work.
+3. Run `codesdd sdd context <FEAT-ID>` before drafting architecture changes.
 4. Keep `.sdd/active/<FEAT-ID>/5-quality.yaml` updated with decision evidence and risks.
-5. Declare interface impact with `opensdd sdd frontend-impact <FEAT-ID> ...` even when status is `none`.
-6. Run `opensdd sdd check --render` after updates; run `opensdd sdd diagnose` when structure drift is suspected.
-7. Consolidate with `opensdd sdd finalize --ref <FEAT-ID>` only after quality evidence is recorded.
+5. Declare interface impact with `codesdd sdd frontend-impact <FEAT-ID> ...` even when status is `none`.
+6. Run `codesdd sdd check --render` after updates; run `codesdd sdd diagnose` when structure drift is suspected.
+7. Consolidate with `codesdd sdd finalize --ref <FEAT-ID>` only after quality evidence is recorded.
 
 ### How to use INS/DEB/EPIC/FEAT as decision layers
 
@@ -368,10 +368,10 @@ Use these prompts and record answers in FEAT notes/quality evidence:
 
 ### Runtime-boundary guardrails
 
-- OpenSDD files and commands are planning/governance tools only.
-- Generated Flask code must not import from `.sdd`, parse OpenSDD YAML, or shell out to `opensdd`.
-- Domain and application layers must stay independent of OpenSDD metadata and CLI semantics.
-- If a project does not use OpenSDD, keep the same architecture rules and capture decisions in equivalent project docs.
+- CodeSDD files and commands are planning/governance tools only.
+- Generated Flask code must not import from `.sdd`, parse CodeSDD YAML, or shell out to `codesdd`.
+- Domain and application layers must stay independent of CodeSDD metadata and CLI semantics.
+- If a project does not use CodeSDD, keep the same architecture rules and capture decisions in equivalent project docs.
 
 ### Quality-contract usage in this mode
 
@@ -382,7 +382,7 @@ For each major architecture decision, update the active FEAT quality artifact wi
 - accepted risks and compensating controls;
 - command evidence (`check --render`, tests, build) and timestamped results.
 
-This keeps decision history auditable without leaking OpenSDD concerns into runtime code.
+This keeps decision history auditable without leaking CodeSDD concerns into runtime code.
 
 ---
 
@@ -2618,7 +2618,7 @@ These gates keep the skill reviewable and traceable to EPIC-0016 without relying
 | --- | --- | --- | --- |
 | GATE-ARCH-BOUNDARY | Domain/application remain framework-free; adapters stay in interface/infrastructure layers | Clean Architecture boundaries and dependency direction | `## Python/Flask Clean Architecture boundary contract`, `Must not depend on` |
 | GATE-SEC-AUTHORITY | Tenant/security authority comes from validated principal (JWT/context), never from payload or LLM output | Tenant isolation and security authority source | `tenant_id obrigatório`, `WebSocket payload is never authority` |
-| GATE-OPENSDD-BOUNDARY | OpenSDD is decision-support only; generated runtime code must not import OpenSDD artifacts | OpenSDD support with runtime boundary safety | `## OpenSDD decision-support mode (never runtime dependency)`, `must not import from `.sdd`` |
+| GATE-CODESDD-BOUNDARY | CodeSDD is decision-support only; generated runtime code must not import CodeSDD artifacts | CodeSDD support with runtime boundary safety | `## CodeSDD decision-support mode (never runtime dependency)`, `must not import from `.sdd`` |
 | GATE-PROD-VERSIONING | Production guidance remains provider/model agnostic and version-sensitive APIs are labeled | Production readiness and version-aware guidance | `## Production-readiness guidance (safe and version-aware)`, `Version-sensitive API policy (validated or conceptual)` |
 | GATE-VALIDATION-STRATEGY | Validation uses stable required anchors/rules instead of prose snapshots | Maintainable quality gate evidence | `Avoid whole-document snapshots`, `Prefer required headings and key rules` |
 
@@ -2632,7 +2632,7 @@ These gates keep the skill reviewable and traceable to EPIC-0016 without relying
 Recommended minimum anchors for seeded-skill tests:
 
 - `## Python/Flask Clean Architecture boundary contract`
-- `## OpenSDD decision-support mode (never runtime dependency)`
+- `## CodeSDD decision-support mode (never runtime dependency)`
 - `## Production-readiness guidance (safe and version-aware)`
 - `Version-sensitive API policy (validated or conceptual)`
 - `Redis Pub/Sub versus Streams and outbox`

package/.sdd/skills/curated/devtrack-api/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: devtrack-api
-description: Model-agnostic engineering skill for the DevTrack Foundation API and derived DevTrack APIs. Use it to implement, review, refactor, test, document, or govern NestJS TypeScript backend work using DDD, Hexagonal Architecture, Clean Architecture, TypeORM, OpenSDD, strict import boundaries, layered modules under domain, application, presentation, infrastructure, and shared, plus safe operational practices, evidence-based validation, and quality handoff.
+description: Model-agnostic engineering skill for the DevTrack Foundation API and derived DevTrack APIs. Use it to implement, review, refactor, test, document, or govern NestJS TypeScript backend work using DDD, Hexagonal Architecture, Clean Architecture, TypeORM, CodeSDD, strict import boundaries, layered modules under domain, application, presentation, infrastructure, and shared, plus safe operational practices, evidence-based validation, and quality handoff.
 ---
 
 # DevTrack API
@@ -19,7 +19,7 @@ These rules apply to any assistant, automation host, IDE agent, command-line cod
 - Prefer repository evidence over memory, assumptions, examples, or generated guesses.
 - Do not invent APIs, flags, files, package scripts, class names, module names, environment variables, database objects, or behavior.
 - Verify version-sensitive details from local files such as `package.json`, lockfiles, configs, migrations, source code, or official docs when available.
-- Keep work scoped to the user request and the active OpenSDD feature when one exists.
+- Keep work scoped to the user request and the active CodeSDD feature when one exists.
 - Preserve user changes in a dirty worktree. Never overwrite unrelated modifications.
 - Avoid destructive actions unless the user explicitly requested them and the scope is clear.
 - Never expose, copy, log, commit, or summarize real secrets.
@@ -29,14 +29,16 @@ These rules apply to any assistant, automation host, IDE agent, command-line cod
 
 ## Operating Mode
 
-Repository files are the source for implementation facts. OpenSDD is the source for operational planning, progress, dependencies, blockers, quality, and handoff.
+Repository files are the source for implementation facts. CodeSDD is the source for operational planning, progress, dependencies, blockers, quality, and handoff.
+
+When CodeSDD is governing a project and the user asks for API or backend work without explicitly selecting another skill/profile, `devtrack-api` is the default API skill. Explicit Python/Flask/LangGraph API work uses the dedicated Python skill/profile instead.
 
 Before edits in the API repository:
 
 1. Read the nearest `AGENTS.md` and `AGENT.md`.
-2. Run `opensdd sdd onboard system`.
-3. Run `opensdd sdd next`.
-4. If SDD returns a ready or active feature id, run `opensdd sdd context <FEAT-ID>` before coding.
+2. Run `codesdd sdd onboard system`.
+3. Run `codesdd sdd next`.
+4. If SDD returns a ready or active feature id, run `codesdd sdd context <FEAT-ID>` before coding.
 5. If no feature id is available but the user explicitly requested the work, continue narrowly and state the SDD exception in the final handoff.
 6. Check `git status --short` before editing and before the final handoff.
 7. Inspect nearby implementation files before creating new patterns.
@@ -56,9 +58,13 @@ Treat the repository as a production-grade system:
 
 ## Reference Map
 
-Load only the files needed for the task, but always load governance before code changes:
+Load only the files needed for the task, but always load governance and layout before code changes:
 
+- Always read [contract-pack.yaml](references/contract-pack.yaml) before planning, approving, or executing a `devtrack-api` project, debate, EPIC, or FEAT. It is the machine-readable contract pack for derivation profiles, P0/P1/P2 severity, early package preview, human validation, and `codesdd-validate` drift remediation.
 - Always read [architecture-governance.md](references/architecture-governance.md) before code changes.
+- Always read [foundation-layout.md](references/foundation-layout.md) before producing any implementation plan, debate, or code change that proposes new file paths. Foundation layout is canonical, not advisory.
+- Read [consumer-sync-policy.md](references/consumer-sync-policy.md) before copying, updating, validating, or accepting `devtrack-api` in a consumer repository.
+- Read [field-validation-protocol.md](references/field-validation-protocol.md) before declaring `devtrack-api` adoption validated in a consumer project or closing field-evidence expectations.
 - Read [imports-lint.md](references/imports-lint.md) before editing imports or fixing lint.
 - Read [domain-modeling.md](references/domain-modeling.md) for `domain/`, `.type.ts`, `.bo.ts`, `.vo.ts`, validators, events, and repository ports.
 - Read [application-presentation.md](references/application-presentation.md) for use cases, services, handlers, ports, modules, controllers, DTO validators, GraphQL, CLI, WebSocket, agents, and tools.
@@ -66,6 +72,20 @@ Load only the files needed for the task, but always load governance before code
 - Read [testing-validation.md](references/testing-validation.md) before finishing or when choosing tests.
 - Use [implementation-checklist.md](references/implementation-checklist.md) as the final pass checklist.
 
+## Contract Pack And Derivation Profiles
+
+The structured contract lives in [contract-pack.yaml](references/contract-pack.yaml). Treat it as the executable policy source that future CodeSDD gates can import. The Markdown skill explains the rules; the YAML contract names the profiles, severities, rule ids, drift map, and evidence expectations.
+
+Every `devtrack-api` plan must select exactly one profile before implementation:
+
+- `prototype`: exploratory only. It cannot be reported as Foundation-compatible unless a later FEAT upgrades and validates it.
+- `foundation-compatible`: default for derived DevTrack APIs. P0 drift blocks finalize; P1 drift requires remediation or formal exception.
+- `enterprise-strict`: audit-grade mode. P0 and P1 drift block finalize; P2 drift requires evidence or ADR-backed exception.
+
+For the first two or three DEBs of a new `devtrack-api` project or major API theme, CodeSDD must generate a package-structure preview and ask the human planner to approve or correct it before FEAT execution. Missing profile selection, missing preview, missing human validation, or declarative-only skill evidence are contract defects.
+
+The `codesdd-validate` field failure is mapped in the contract pack under `codesdd_validate_drift_map`. Future planning, validator, finalize, provenance, and field-validation FEATs must consume that map instead of reinterpreting the failure from memory.
+
 ## Layer Order
 
 Implement from inside out unless the task is purely presentation or infrastructure:
@@ -83,29 +103,141 @@ Dependency direction is strict:
 - `presentation` must not import concrete infrastructure.
 - `infrastructure` implements ports defined by `domain` or `application`.
 
-## Non-Negotiable Naming
-
-- Domain types: `src/domain/<context>/types/<name>.type.ts`.
-- Business objects: `src/domain/<context>/business-objects/<name>.bo.ts`.
-- Value objects: `src/domain/<context>/value-objects/<name>.vo.ts`.
-- Domain entities, where the context already uses entities: `<name>.entity.ts`.
-- Domain repository ports: `src/domain/<context>/repository-ports/<name>-repository.port.ts`.
-- Application ports: `src/application/<context>/<module>/ports/in/*.port.ts` and `ports/out/*.port.ts`.
-- Use cases: `<verb-noun>.use-case.ts`.
-- Services: `<name>.service.ts`.
-- Handlers: `<name>.handler.ts`.
-- REST controllers: `<verb-noun>.controller.ts`, one controller class per file.
-- Presentation validators: `<verb-noun>.presentation-validator.ts`.
-- TypeORM entities: `<name>.orm-entity.ts`.
-- TypeORM repositories: `<name>.typeorm-repository.ts`.
-- TypeORM mappers: `<name>.mapper.ts`.
-- TypeORM migrations: `<timestamp>-<action>.migration.ts`.
-- Nest modules: `<module>.application.module.ts`, `<module>.module.ts`, or `<module>-orm.module.ts` by layer.
+## Domain Pattern Decision Rule
+
+Before touching domain, decide which of the two coexisting patterns applies. The choice is binary and prescriptive — not stylistic.
+
+- **BO-pattern (default for every new context).** Domain artifacts live as `business-objects/<name>.bo.ts`, `value-objects/<name>.vo.ts`, and `types/<name>.type.ts`. **Do not create** `entities/` or `repository-ports/` folders in domain. Repository ports for this pattern live in **application** (`ports/out/`).
+- **Entity-pattern (legacy, extension only).** Applies only when extending a context that **already uses** `entities/` in `devtrack-foundation-api`. The current legacy set is exactly: `pessoas`, `wallets`. Introducing `entities/` to any other domain context requires an ADR; otherwise it is forbidden.
+
+When in doubt about a context's pattern, verify the physical layout in `devtrack-foundation-api/src/domain/<context>/` — that is the ground truth. The rule is enforced by [foundation-layout.md](references/foundation-layout.md).
+
+## Canonical Paths
+
+These paths are non-negotiable. Any file proposed in an implementation plan, debate, or code change must match one of these patterns exactly.
+
+**Domain (BO-pattern — default)**
+
+```text
+src/domain/<context>/business-objects/<name>.bo.ts
+src/domain/<context>/value-objects/<name>.vo.ts          (optional)
+src/domain/<context>/types/<name>.type.ts
+src/domain/<context>/constants/<name>.const.ts           (optional)
+```
+
+**Domain (entity-pattern — legacy `pessoas` and `wallets` only)**
+
+```text
+src/domain/<context>/entities/<name>.entity.ts
+src/domain/<context>/repository-ports/<name>-repository.port.ts
+src/domain/<context>/validators/<name>.validator.ts
+src/domain/<context>/events/<name>-<event>.event.ts      (optional)
+src/domain/<context>/types/<name>.type.ts
+```
+
+**Shared domain primitives (centralized, never per-context)**
+
+```text
+src/shared/domain/exceptions/<name>.exception.ts
+src/shared/domain/value-objects/<name>.vo.ts
+src/shared/domain/validators/<name>.validator.ts
+src/shared/domain/types/<name>.type.ts
+```
+
+**Application**
+
+```text
+src/application/business/<context>/use-cases/<verb-noun>.use-case.ts
+src/application/business/<context>/ports/in/<verb-noun>.use-case.port.ts
+src/application/business/<context>/ports/out/<name>.port.ts
+src/application/business/<context>/ports/out/<name>-repository.port.ts   (BO-pattern only)
+src/application/business/<context>/services/<name>.service.ts
+src/application/business/<context>/handlers/<name>.handler.ts
+src/application/business/<context>/<context>.application.module.ts
+```
+
+Foundation-compatible intelligence modules are canonical application-layer modules. They use the same boundary rules as `business` modules, with provider-neutral orchestration in application and provider-specific integrations in infrastructure.
+
+```text
+src/application/intelligence/<context>/use-cases/<verb-noun>.use-case.ts
+src/application/intelligence/<context>/ports/in/<verb-noun>.use-case.port.ts
+src/application/intelligence/<context>/ports/out/<name>.port.ts
+src/application/intelligence/<context>/services/<name>.service.ts
+src/application/intelligence/<context>/handlers/<name>.handler.ts
+src/application/intelligence/<context>/agents/<name>.agent.ts
+src/application/intelligence/<context>/tools/<name>.tool.ts
+src/application/intelligence/common/agent-runtime/<name>.ts
+```
+
+Current Foundation intelligence contexts: `common`, `conversation`, `course-agents`, `report-chat`.
+
+**Infrastructure (centralized by subsystem — never by business context)**
+
+```text
+src/infrastructure/adapters/<subsystem>/<name>.adapter.ts
+src/infrastructure/adapters/<subsystem>/<subsystem>.module.ts
+src/infrastructure/adapters/orm/entities/<name>.orm-entity.ts
+src/infrastructure/adapters/orm/repositories/<name>.typeorm-repository.ts
+src/infrastructure/adapters/orm/mappers/<name>.mapper.ts
+src/infrastructure/adapters/orm/migrations/<timestamp>-<action>.migration.ts
+src/infrastructure/adapters/orm/<context>-orm.module.ts
+```
+
+Known subsystems in Foundation: `auth`, `aws`, `cache`, `configuration`, `http`, `llm`, `orm`, `queue`, `redis`, `sync-engine`, `temporal`, `vector-store`. Add a new subsystem folder only when no existing subsystem covers the integration.
+
+**Presentation (segmented by transport before context)**
+
+```text
+src/presentation/rest/<context>/controllers/<verb-noun>.controller.ts
+src/presentation/rest/<context>/dtos/<verb-noun>.dto.ts
+src/presentation/rest/<context>/presentation-validators/<verb-noun>.presentation-validator.ts
+src/presentation/rest/<context>/guards/<name>.guard.ts
+src/presentation/rest/<context>/decorators/<name>.decorator.ts
+src/presentation/rest/<context>/<context>.module.ts
+```
+
+REST DTOs are transport-layer input/output contracts. Keep them thin and delegate validation/mapping into presentation validators and application use cases.
+
+Other transports follow the same shape under `graphql/`, `cli/`, `websocket/`, or `agent/`.
+
+**Suffix-only rules (orthogonal to path)**
+
+- Use cases end with `.use-case.ts`. Services with `.service.ts`. Handlers with `.handler.ts`.
+- REST controllers end with `.controller.ts`, one class per file.
+- REST DTOs end with `.dto.ts`.
+- Presentation validators end with `.presentation-validator.ts`.
+- Nest modules end with `.application.module.ts`, `.module.ts`, or `-orm.module.ts` by layer.
+
+## Forbidden Patterns
+
+These layouts have been observed in derived debates and plans and **must be rejected**. Each one violates the canonical paths above.
+
+- `src/domain/<context>/exceptions/` — use `src/shared/domain/exceptions/`. Exceptions are centralized.
+- `<name>.schema.ts` for TypeORM entities — use `<name>.orm-entity.ts`.
+- `<name>.value-object.ts` — use `<name>.vo.ts`.
+- `<name>.repository.ts` (ambiguous) — use `<name>.typeorm-repository.ts` in infrastructure, `<name>-repository.port.ts` in port.
+- `src/infrastructure/<context>/persistence/typeorm/` — use `src/infrastructure/adapters/orm/`.
+- `src/infrastructure/<context>/adapters/` — use `src/infrastructure/adapters/<subsystem>/`.
+- `src/infrastructure/<context>/repositories/` — use `src/infrastructure/adapters/orm/repositories/`.
+- `src/presentation/<context>/` (transport-less) — use `src/presentation/rest/<context>/` (or another transport).
+- `entities/` in any new domain context — use `business-objects/`. The legacy set is closed: `pessoas`, `wallets`.
+- `repository-ports/` in any new domain context — declare the port in application `ports/out/`.
+
+## Plan-Time Conformance Gate
+
+When producing an implementation plan (the "Arquivo NestJS | Ação" table inside a DEB-*.md, a `2-plan.yaml` task list, or any file inventory in a discovery artifact), apply this gate **before** publishing the plan:
+
+1. For each proposed path, match it against Canonical Paths. If it does not match, replace it with the canonical equivalent or flag it as an explicit architectural divergence requiring ADR.
+2. For each new domain context, declare the chosen pattern (BO or entity) and justify the choice. The default is BO; declaring entity for a new context requires citing the ADR.
+3. Cross-check against [foundation-layout.md](references/foundation-layout.md). Skill compliance is verifiable: every path either exists as a pattern in Foundation or is forbidden.
+
+A plan that fails this gate corrupts the downstream FEAT execution and the discovery quality ledger. Fix the plan before merging the debate.
 
 ## Imports And Lint First Principles
 
 - Do not use relative imports in `src` or tests. Even same-folder imports are forbidden.
-- Use aliases: `@domain/*`, `@application/*`, `@presentation/*`, `@infrastructure/*`, `@infrastructure/adapter/*`, `@shared/*`, `@src/*`.
+- Use aliases: `@application/business/notifications/ports/out/*`, `@domain/*`, `@application/*`, `@presentation/*`, `@infrastructure/adapter/*`, `@infrastructure/*`, `@shared/*`, `@src/presentation.module`, `@src/application.module`, `@src/*`, `@tests/*`.
+- Derived projects must carry the Foundation-compatible `tsconfig` alias map before claiming Foundation compatibility.
 - Use `import type` for type-only imports.
 - Keep domain free of Nest, TypeORM, class-validator, HTTP, queue, AWS, cache, LLM, and framework concepts.
 - Treat lint warnings as design feedback, not cosmetic noise.
@@ -129,9 +261,9 @@ Before final response on API work:
 1. Run the smallest useful tests first, then broaden if the change crosses layers.
 2. Prefer `pnpm lint` and `pnpm build` for structural changes.
 3. Update `.sdd/active/<FEAT-ID>/5-quality.yaml` when an active feature exists and completion evidence is in scope.
-4. Declare frontend impact with `opensdd sdd frontend-impact <FEAT-ID> ...` when an active feature exists and the feature is being completed.
+4. Declare frontend impact with `codesdd sdd frontend-impact <FEAT-ID> ...` when an active feature exists and the feature is being completed.
 5. Update affected docs required by SDD when the task changes architecture or behavior.
-6. Run `opensdd sdd finalize --ref <FEAT-ID>` only when feature completion is actually in scope.
+6. Run `codesdd sdd finalize --ref <FEAT-ID>` only when feature completion is actually in scope.
 7. Final handoff must include changed areas, validation commands and results, skipped checks with reasons, SDD exception if any, and residual risks.
 
 Never claim validation passed unless the command actually ran successfully.

package/.sdd/skills/curated/devtrack-api/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "DevTrack API"
   short_description: "Portable DevTrack API engineering governance, architecture, safety, validation, and quality skill."
-  default_prompt: "Use $devtrack-api to implement, review, refactor, test, or document DevTrack API work with OpenSDD, DDD/Clean Architecture, TypeORM, strict import boundaries, evidence-based validation, and safe operational constraints."
+  default_prompt: "Use $devtrack-api to implement, review, refactor, test, or document DevTrack API work with CodeSDD, DDD/Clean Architecture, TypeORM, strict import boundaries, evidence-based validation, and safe operational constraints."

package/.sdd/skills/curated/devtrack-api/references/architecture-governance.md

@@ -13,11 +13,11 @@ Use this precedence when context conflicts:
 1. Current repository files for implementation facts.
 2. Nearest `AGENTS.md` / `AGENT.md` for local agent instructions.
 3. `.sdd/state/*.yaml` for operational state, planning, progress, dependencies, blockers, quality, and handoff.
-4. `.sdd/core/*.md`, `.sdd/planning/*.md`, `.sdd/AGENT.md`, and `.sdd/README.md` as OpenSDD operational views and guides.
+4. `.sdd/core/*.md`, `.sdd/planning/*.md`, `.sdd/AGENT.md`, and `.sdd/README.md` as CodeSDD operational views and guides.
 5. Skill reference files as architecture and quality policy.
 6. Historical notes, generated summaries, or legacy docs only when confirmed by current repository evidence.
 
-Do not let old notes override the codebase or OpenSDD. If useful legacy material exists, repatriate the decision into OpenSDD and remove or ignore the legacy artifact.
+Do not let old notes override the codebase or CodeSDD. If useful legacy material exists, repatriate the decision into CodeSDD and remove or ignore the legacy artifact.
 
 ## Model Neutrality
 
@@ -44,14 +44,14 @@ Agents must be conservative with facts.
 Before edits:
 
 ```bash
-opensdd sdd onboard system
-opensdd sdd next
+codesdd sdd onboard system
+codesdd sdd next
 ```
 
-If `opensdd sdd next` returns a ready or active feature id:
+If `codesdd sdd next` returns a ready or active feature id:
 
 ```bash
-opensdd sdd context <FEAT-ID>
+codesdd sdd context <FEAT-ID>
 ```
 
 Also before edits:
@@ -65,7 +65,7 @@ Rules:
 - Read nearest `AGENTS.md` and `AGENT.md` before editing.
 - Inspect nearby files before introducing new patterns.
 - If there is no feature id but the user explicitly asked for work outside SDD, state the exception in the final handoff.
-- Create an OpenSDD insight or feature only when durable follow-up is required.
+- Create an CodeSDD insight or feature only when durable follow-up is required.
 - Do not create external context notes, workflow state, backlog, project memory, scratchpads, or handoff stores.
 - Do not use BRV.
 
@@ -137,6 +137,7 @@ Current contexts include:
 The canonical intelligence boundary is:
 
 - `src/application/intelligence/conversation/`: omnichannel boundary.
+- `src/application/intelligence/course-agents/`: course-oriented agent orchestration.
 - `src/application/intelligence/report-chat/`: specialized capability.
 - `src/application/intelligence/common/agent-runtime/`: generic runtime ownership.
 - `src/domain/intelligence/`: single domain aggregate with `business-objects/`, `value-objects/`, and `types/`.

package/.sdd/skills/curated/devtrack-api/references/consumer-sync-policy.md

@@ -0,0 +1,93 @@
+# devtrack-api Consumer Copy Sync Policy
+
+## Scope
+
+This policy governs every copy of `.sdd/skills/curated/devtrack-api/` that CodeSDD materializes into a consumer repository.
+
+It covers:
+
+- `SKILL.md`
+- `agents/openai.yaml`
+- all files under `references/`, including `contract-pack.yaml`
+
+It does not make CodeSDD the canonical backend implementation source. `devtrack-foundation-api` remains the backend architecture ground truth; CodeSDD owns the skill distribution and consumer materialization contract.
+
+## Authority
+
+- Canonical CodeSDD source: `.sdd/skills/curated/devtrack-api/` in this repository.
+- Canonical catalog entry: `.sdd/state/skill-catalog.yaml` skill id `devtrack-api`.
+- Canonical backend layout evidence: `devtrack-foundation-api/src/`, validated by `test/specs/devtrack-api-foundation-layout.test.ts`.
+- Canonical machine-readable skill policy: `.sdd/skills/curated/devtrack-api/references/contract-pack.yaml`.
+- Consumer copy: `<consumer-root>/.sdd/skills/curated/devtrack-api/`.
+
+Consumer copies are one-way materializations from CodeSDD. They are not a second source of truth and must not be used as an upstream patch queue.
+
+## Required Sync Events
+
+Synchronize and verify the consumer copy:
+
+1. after upgrading the CodeSDD version, commit, or distribution bundle used by the consumer project;
+2. before executing a consumer FEAT that explicitly uses or is routed to `devtrack-api`;
+3. after a Foundation layout change that affects domain, application, infrastructure, presentation, testing, or governance guidance;
+4. after any temporary local hotfix to a consumer copy, once the canonical CodeSDD correction exists.
+
+## Sync Procedure
+
+1. In the CodeSDD repository, validate the canonical skill before distribution:
+
+   ```bash
+   pnpm exec vitest run test/specs/devtrack-api-foundation-layout.test.ts test/core/sdd/skill-distribution.test.ts
+   pnpm run build
+   ```
+
+2. In the consumer repository, refresh CodeSDD materialization with the configured project update flow:
+
+   ```bash
+   codesdd update
+   ```
+
+   For a new consumer project, run the bootstrap/init flow used by that project before comparing the generated skill copy.
+
+3. Compare the canonical source and the consumer copy:
+
+   ```bash
+   diff -ru <codesdd-root>/.sdd/skills/curated/devtrack-api <consumer-root>/.sdd/skills/curated/devtrack-api
+   ```
+
+   Expected result: no diff when the consumer is on the same CodeSDD commit or release. A pinned older consumer may differ only when the handoff records the pin and the reason.
+
+4. Record evidence in the consumer FEAT quality or handoff:
+
+   - CodeSDD commit or release tag used as the source.
+   - Foundation checkout path, commit, or release used for validation when available.
+   - update/bootstrap command used in the consumer repository.
+   - diff command and result.
+   - any intentional pin, exception, or follow-up SDD reference.
+
+## Local Edit Rule
+
+Do not make durable edits directly in a consumer copy of `devtrack-api`.
+
+If a consumer copy needs an urgent local correction:
+
+1. mark it as temporary in the consumer handoff;
+2. open or link a CodeSDD INS/DEB/FEAT for the canonical correction;
+3. replace the local edit with a normal CodeSDD materialization after the canonical correction is released;
+4. keep the consumer FEAT blocked or excepted if the local edit changes architecture, security, persistence, or validation rules.
+
+## Conflict Handling
+
+- If Foundation changed and CodeSDD did not, update the CodeSDD skill and conformance test first.
+- If a consumer copy changed and CodeSDD did not, repatriate the useful change through CodeSDD discovery before accepting it anywhere else.
+- If the diff is not empty and there is no documented version pin, treat the consumer copy as stale.
+- If a generated consumer copy is stale, do not "fix" only the generated copy. Refresh from CodeSDD or create the canonical CodeSDD correction first.
+
+## Acceptance Checklist
+
+A consumer copy is current only when:
+
+- `SKILL.md`, `agents/openai.yaml`, and every `references/*.md` file match the intended CodeSDD source commit or release;
+- `references/contract-pack.yaml` matches the intended CodeSDD source commit or release;
+- the consumer FEAT quality or handoff records source version, update command, and diff result;
+- no durable edits exist only in the consumer copy;
+- any Foundation-driven guidance change passed the CodeSDD Foundation-layout conformance test first.