commission

name	commission
description	Commission an implementation — drive the orchestrator to take canonical implementation.json + useCase YAMLs through audit → charter → mount → verify → certify
disable-model-invocation	false
argument-hint	[implementation-code]

Commission an Implementation

The canonical entry point is data/industries/<industry>/implementations/<code>/implementation.json + referenced useCase YAMLs at data/industries/<industry>/useCases/<code>/useCase.yaml. Derived per-impl artifacts land at data/industries/<industry>/implementations/<impl>/forge/.

Master entry point. Takes an implementation code whose canonical artifact lives at data/industries/<industry>/implementations/<implementation-code>/implementation.json, then drives the full lifecycle through the orchestrator.

This skill is a translator. Every stage maps 1:1 to an orchestrator / assemble / commission subcommand. Claude does not chain fill/seed/migrate by hand, never re-invents a process, and never confirms with the user between phases — the orchestrator and its classifiers are the decision layer.

Forge is per-useCase only. Commission drives Forge once per useCase in implementation.useCases[]. Forge phases (Map / Trace / Devise) require design judgment because they author the per-useCase artifacts that later stages consume. Assemble is deterministic — no judgment in the code path; AI invocation lives behind @artifactjs/handshake beacons.

Reference

• .claude/rules/implementation-process.md — vocabulary + stage definitions
• .claude/rules/forge-assemble-split.md — load-bearing architectural rule
• .claude/rules/translator-role.md — why this skill cannot improvise processes
• .claude/rules/handshake-protocol.md — how AI is summoned through structured beacons
• commission/assemble/CLAUDE.md — the Assemble package contract
• verification/appraise/CLAUDE.md — what the Implementation declares and how it is checked

Flow:

implementation.json (selection record: { implementation, useCases: [{ code, templateKey, bindings }] })
  → For each useCase: Forge (Map → Trace → Devise) per (template + bindings)
  → Assemble (compose → source → manifest → constitution → pillar-verdicts)
  → Audit → Charter → Audit → Mount → [Populate] → Certify → Appraise
  → Implementation

Square brackets mark stages that are optional or conditionally skipped; Appraise is the conformance gate — it is always run and is the only stage grounded in the human-authored Implementation.

Implementation format (v6 selection record)

The Implementation is JSON at data/industries/<industry>/implementations/<implementationCode>/implementation.json. It is an impl-level selection record — it declares which useCases the implementation hosts and the bindings each useCase carries. Structural shape lives in the canonical useCase YAMLs at data/industries/<industry>/useCases/<code>/useCase.yaml. Reference: data/industries/<industry>/implementations/application-ophtha-clinic-dev/implementation.json.

{
  "implementation": "application-foo-dev",
  "industry": "health",
  "summary": "One-line description of what the implementation does.",
  "useCases": [
    {
      "code": "usecase-foo-clinical",
      "bindings": {
        "userMode": "usermode-user",
        "domainScope": ["domain-eye"],
        "summary": "...",
        "pathwayWorkflows": ["workflow-master-surgery-data"],
        "pathwayProtocols": ["protocol-phaco-protocol"],
        "acceptanceCriteria": ["..."]
      }
    }
  ]
}

Field	What it is
useCases[i].code	Kebab-case identifier — references the canonical useCase YAML. Stable across runs.
useCases[i].bindings	Variant content for THIS useCase: userMode, domainScope, pathway declarations, label overrides, acceptanceCriteria, status, riskClass. Implementation-level overrides; the useCase YAML carries its own defaults.

Optional impl-level fields: industry, editionTarget, status, actors[], userModes[], constraints[], presentation (entity label overrides), navigationOverrides.

Legacy features[] is no longer authored — it is synthesized at load time from useCases[] for appraise checkers that haven't migrated. See verification/appraise/src/loadCommissionContext.ts § synthesiseFeaturesFromUseCases.

There is no markdown implementation template. Implementations are structured JSON, not prose. Templates were retired on 2026-05-04 — data/useCaseTemplates/ and data/templates/ were deleted; new useCases are scaffolded empty (forge usecase create --code <code>) or forked (forge usecase fork --from <existing> --to <new>).

Invocation

When the user runs /commission <implementation-code>:

1. Resolve the implementation via data/tenants/implementations.csv (tenant, network, edition).
2. Read data/industries/<industry>/implementations/<implementation-code>/implementation.json. If missing, stop and tell the user to author one (or fork an existing implementation).
3. Edit useCases and directives directly in the IDE (canonical YAMLs at data/industries/<industry>/useCases/<code>/useCase.yaml and data/industries/<industry>/{application,editions/<edition>/application}/directives/<uuid>.yaml). Use forge usecase, wire directive, and assemble impl verbs — not phase scripts.
4. Drive the rest of the lifecycle through the orchestrator without pausing for per-phase confirmation.
5. Emit the final Appraise verdict.

Forge — IDE editing (no phases)

Forge is no longer a phase-runner. The Map / Trace / Devise / Source CLI scripts were retired on 2026-05-04. Cascade design happens through editing primitives that mutate the canonical YAMLs in place; trace.yaml and the edition CSVs are derived inside Assemble.

Catalog coverage for one useCase

Replaces the old forge map --implementation pre-Forge gap report. Stdout-only, no on-disk artifact.

pnpm --filter @authoring/forge exec tsx src/cli.ts usecase coverage --code <useCaseCode>

Tells you: how many directiveRefs resolve in the shared catalog vs edition-local vs missing; what pathways the useCase declares; which implementations consume this useCase.

Editing a useCase

forge usecase list                              # filter by industry / domain / has-directive
forge usecase show           --code <code>      # full pretty-print
forge usecase create         --code <code>      # scaffold empty useCase (or fork instead)
forge usecase fork           --from <code> --to <code>
forge usecase add-directive  --code <code> --directive <uuid>
forge usecase remove-directive --code <code> --directive <uuid>

Editing a directive

wire directive list           [--target <intent>] [--shared|--edition <code>]
wire directive show           --uuid <uuid>
wire directive create         --uuid <uuid> --target <intent> [--from <existing>]
wire directive fork           --from <uuid> --to <uuid>
wire directive lift           --uuid <uuid>           # edition-local → shared
wire directive reduce         --uuid <uuid> --edition <code>
wire directive regenerate-csv [--shared | --edition <code> | --all]
wire audit drift                                       # YAML ↔ directives.csv drift

Implementation editing

assemble impl create         --code <code> --useCases <a,b,...>
assemble impl add-usecase    --code <code> --useCase <code>
assemble impl remove-usecase --code <code> --useCase <code>
assemble impl fork           --from <code> --to <code>

Gap analysis (formerly Devise)

Gap detection lives in verification/appraise checkers (semantics, instance-semantics, navigation, pathway-coverage, domain-instances). Run after editing:

pnpm --filter @commission/orchestrator exec tsx src/cli.ts appraise --implementation <code>

Aggregating into edition CSVs

When the IDE edits are done, drive Assemble to compose → trace → source the per-useCase YAMLs into edition CSVs:

pnpm --filter @commission/assemble exec tsx src/cli.ts all --impl <code>

Lifecycle — orchestrator drives it

Every stage below is a single orchestrator subcommand. Do not run the underlying fill/seed/migrate CLIs directly — they are denied by .claude/settings.json and the orchestrator exists to compose them.

Invocation prefix:

pnpm --filter @commission/orchestrator exec tsx src/cli.ts <stage> --implementation <code>

Charter

Register the deployment — network directory, implementation record, tenant config.

pnpm --filter @commission/orchestrator exec tsx src/cli.ts charter --implementation <code>

Audit

Static integrity check of the CSV cascade + charter. Runs after Forge (on the implementation the user just sourced) and again after Charter.

pnpm --filter @commission/orchestrator exec tsx src/cli.ts audit --implementation <code>

Mount

Migrate + Load — applies DB migrations if Appoint introduced new descriptors, then fills and seeds.

pnpm --filter @commission/orchestrator exec tsx src/cli.ts mount --implementation <code>

Use --nuke to drop and recreate the tenant DB first. Use reload (not mount) when iterating on CSV edits without schema changes.

Populate (optional, dev/test only)

Create representative runtime data through the GraphQL API. Prerequisite for Certify's read/write view diagnostics.

pnpm --filter @commission/orchestrator exec tsx src/cli.ts populate --implementation <code>

Certify

Browser-driven view compliance — screenshots + design-system checks per directive.

pnpm --filter @commission/orchestrator exec tsx src/cli.ts certify --useCase <useCaseCode> --implementation <code>

Appraise — the Implementation conformance gate

Runs the checkers in verification/appraise/src/checkers/: fulfills-intents, intents-have-structure-data, must-render-fields, must-flow-actions. Failures carry a classifier hint telling you exactly which CSV row or structureData entry is missing.

pnpm --filter @commission/orchestrator exec tsx src/cli.ts appraise --implementation <code>

Composite — run everything

The commission subcommand chains charter → audit → mount → verify → [populate] → [certify] → appraise with halt-on-FAIL:

pnpm --filter @commission/orchestrator exec tsx src/cli.ts commission \
  --implementation <code> --useCase <useCaseCode>

Flags: --nuke, --skip-populate, --populate-only, --skip-certify, --skip-appraise (when no implementation.json exists).

What Claude does on failure

1. The orchestrator emits a structured Escalation (JSON) to stdout. Read it.
2. If verdict === 'PASS', advance.
3. If verdict !== 'PASS', look at each classification's suggestion.hint. The classifier already named the file and the row type that needs editing.
4. Apply the fix (CSV edit, structureData edit, new directive, etc.), then re-run the stage. Do not loop by running arbitrary scripts — the orchestrator's convergence loop handles retries within a single invocation; between invocations, one targeted edit per failure.
5. If a failure is category: 'manual' or has no autofix path, surface the hint to the user and stop.

Rules

• Never run fill/seed/migrate directly. Denied by settings. Use the orchestrator.
• Never improvise a process. If the user asks for something with no registered subcommand, respond: "No registered binding for this — should we add one as code first?" See .claude/rules/translator-role.md.
• Do not confirm between phases. The orchestrator's halt-on-FAIL behavior is the confirmation mechanism.
• Autonomous except Forge. Map/Appoint/Trace/Devise/Source are where Claude exercises judgment. Everywhere else, translate the user's verb into the registered command and run it.
• Reuse before authoring. Before adding a directive, grep data/health/application/directives.csv (shared catalog, 149 rows) and the target edition's directives.csv. A new directive is only warranted when no existing UUID fits.
• uuid === code and follow .claude/rules/uuid-convention.md when authoring new CSV rows.