@wairon/cli 5.1.1-dev.110 → 5.1.1-dev.111

package/dist/templates/skills/sdd-delegate.md

@@ -24,11 +24,12 @@ You are the **Delegation Orchestrator**. Your job is to hand scoped work to a fo
    - Pick the agent whose `ownedPaths`/domain matches the task. If no agent fits, stop and tell the user the topology has a gap.
 2. **Fetch the LIVE brief**:
    - Call `sdd_get_agent_brief(agentId)` (or read the `wairon-agent://<agentId>` resource).
-   - The brief carries: `agentId`, `name`, `template`, `domainRoot?`, `ownedPaths`, `readPaths?`, `instructions`, `variantGuidance?`, `typeMapping?` (how the contracts' neutral types are spelled in the language the agent's code is written in, also folded into `instructions` under `## Types in <language>`; TypeScript's table is the one code conformance reads back, while Rust's and Python's are mapping-only tables the code analyzer does not check, and the table says so), `codeFence?` (where the agent may write code — for a subsystem owner also the project's shared setup files: manifest, compiler settings, crate or package root), an `## Externals used` section for a component reaching another project (each alias, the names it uses, the producer's transport and abi, and the pinned snapshot `.wai/externals/<alias>.yaml`, which joins `readPaths` — code against the pin, never the producer's source), and — when the project opted into `execution.tier` — `profile` and `budget`.
+   - The brief carries: `agentId`, `name`, `template`, `domainRoot?`, `ownedPaths`, `readPaths?`, `instructions`, `variantGuidance?`, `typeMapping?` (how the contracts' neutral types are spelled in the language the agent's code is written in, also folded into `instructions` under `## Types in <language>`; TypeScript's table is the one code conformance reads back, while Rust's and Python's are mapping-only tables the code analyzer does not check, and the table says so), `codeFence?` (where the agent may write code: exactly the files its specs alone name — its implementation, method, simPath and binding files and the files of the types it owns — planned ones included, never a folder glob, so parallel fences never overlap), `sharedPaths?` (files it may touch but does not own: files other components' specs name too, such as a shared type module, and the module setup on the way to its code — manifests, compiler settings, package roots — plus unnamed helpers beside it), an `## Externals used` section for a component reaching another project (each alias, the names it uses, the producer's transport and abi, the pinned snapshot `.wai/externals/<alias>.yaml`, which joins `readPaths` — code against the pin, never the producer's source — and the binding modules its implementations name), and — when the project opted into `execution.tier` — `profile` and `budget`.
    - **Never reuse a brief across delegations or after a re-lock** — fetch fresh per delegation; the call is cheap and the brief is always current.
 3. **Spawn a GENERIC subagent from the brief**:
    - Prompt: `brief.instructions`, plus the concrete task description.
-   - Write fence: the subagent may only modify files matching `brief.ownedPaths` (within `brief.domainRoot` when set). The fence holds every code location the specs name, existing or planned; a planned file is marked `(planned — create it)` and the subagent creates it there. When the brief names no code location, declare the planned `sourcePath` first (`sdd_update_spec` on the implementation) — code linkage is not part of the approval, so this costs no re-lock — and fetch the brief again.
+   - Write fence: the subagent writes code in the files `brief.codeFence` lists (and tests beside them), its spec files in `brief.ownedPaths`. The fence is exact files, existing or planned; a planned file is marked `(planned — create it)` and the subagent creates it there — including the file of a type it owns, never a local copy of the type. When the brief names no code location, declare the planned `sourcePath` first (`sdd_update_spec` on the implementation) — code linkage is not part of the approval, so this costs no re-lock — and fetch the brief again. Fences of sibling components never overlap, so their subagents can run in parallel without you narrowing anything.
+   - Shared files: `brief.sharedPaths`, and any file no spec names (a shared helper, the composition root, test setup, a module manifest beside the code), may be created or extended only for this component's needs — a module setting so its tests run in place, a wiring line, a shared type at its planned home exactly as its spec declares it — and the report names each one touched. A shared or unnamed file that would need a responsibility of its own (domain logic, held state, a decision the design does not make) is a design change: the subagent stops and reports it. When siblings run in parallel, give each shared file one writer (or sequence the waves) — the brief cannot know which sibling runs first.
    - Required first reading: `brief.readPaths` — the subagent reads these before any edit.
    - Pass `brief.variantGuidance` along when present, and `brief.typeMapping` — the subagent writes `list<T>`, `T?`, `async T`, `result<T, E>` and an enum by that mapping, never by guess.
 4. **Apply `brief.budget` when it is present** — constituting the subagent correctly is part of spawning it, not a separate concern. When the brief carries no budget the project has not opted in; spawn as you otherwise would.
@@ -42,7 +43,7 @@ You are the **Delegation Orchestrator**. Your job is to hand scoped work to a fo
 5. **The subagent does the work**:
    - For component implementation it follows the `sdd-implement` skill (gating checks, AI-TDD, narrative coding) and reports back: what changed, test results, anything out of scope.
 6. **Review & integrate**:
-   - Read the report, verify the write fence was respected, and continue orchestrating — or delegate the next scoped task.
+   - Read the report, verify the write fence was respected (code only in `codeFence`; every shared or unnamed file it touched named in the report, for this component's needs only), and continue orchestrating — or delegate the next scoped task.
 
 This flow is transport-agnostic: it works identically over local stdio and the hosted data plane — the tools and `wairon-agent://` resources are the same surface.
 

package/dist/templates/skills/sdd-implement.md

@@ -51,9 +51,9 @@ You are the **Spec-to-Code Compiler**. Your job is to generate concrete source c
    - Confirm the design is approved: `sdd_get_status` reports "Approved: …" and does not list any of this component's specs as changed since the approval. If there is no approval on record, or this component's specs changed after it, stop immediately and ask the human to review the design and run `wairon lock` (never run it yourself).
 2. **Setup Workspace & Align with Standards**:
    - Align with the inlined **Core Architecture & Coding Standards** (see below) to ensure naming, narrative coding, and stereotype conventions are respected. Do NOT read these standards from disk; they are already fully specified in your system context.
-   - Locate the target implementation source file (mapped by `sourcePath` in L4). A file the brief marks `(planned — create it)` does not exist yet: create it at exactly that path — the fence already holds it. A named file not written yet is only `SOURCE_FILE_PLANNED` (a notice), at method level as at implementation level; once any file a component names exists, a contract method naming no file is `METHOD_SOURCE_PATH_MISSING` and one its existing file does not hold is `UNREALIZED_METHOD`.
+   - Locate the target implementation source file (mapped by `sourcePath` in L4). A file the brief marks `(planned — create it)` does not exist yet: create it at exactly that path — the fence already holds it. The fence (`codeFence`) is exact files: write code only there, tests beside them. A type the brief fences is yours to create at its planned home; a shared type file (`sharedPaths`) is created there too, exactly as its spec declares it — never redeclare a type in your own file. Shared files, and files no spec names (a helper, the composition root, test setup, a module manifest so the tests run in place), may be created or extended only for this component's needs; name each one in your report. One that would need a responsibility of its own (domain logic, held state, a decision the design does not make) is a design change: stop and report it. A named file not written yet is only `SOURCE_FILE_PLANNED` (a notice), at method level as at implementation level; once any file a component names exists, a contract method naming no file is `METHOD_SOURCE_PATH_MISSING` and one its existing file does not hold is `UNREALIZED_METHOD`.
    - **Code linkage is not approval.** `sourcePath`, `symbol`, `exportedVia`, `simPath`, `injectedParams` and conformance tiers say where the design is realized, not what it is: they are outside the approved digests. When the implementation names no `sourcePath` yet, or names the wrong file, set it with `sdd_update_spec` — it costs no re-lock and never turns the approval stale.
-   - **Externals.** A contract you consume from another project is judged against its pin. If `sdd_validate_tree` reports an ADVISORY `EXTERNAL_LIVE_INCOMPATIBLE` (a used member changed, was renamed — the new name is given — or is gone in the live producer), adapt the uses, then ask the human to re-pin (`wairon externals pin <alias>`). Advisory findings never fail the gate; they are not a reason to stop, nor to code against the live producer's new shape without adapting the spec first.
+   - **Externals.** A contract you consume from another project is judged against its pin. If `sdd_validate_tree` reports an ADVISORY `EXTERNAL_LIVE_INCOMPATIBLE` (a used member changed, was renamed — the new name is given — or is gone in the live producer), adapt the uses, then ask the human to re-pin (`wairon externals pin <alias>`). Advisory findings never fail the gate; they are not a reason to stop, nor to code against the live producer's new shape without adapting the spec first. When your code reaches a producer through a hand-written binding module (a typed binding to a native library, a client stub), name it on the implementation as `bindings` (code linkage, no re-lock) and write the producer's names in it exactly as the pin has them: `validate` compares the binding with the pin and reports a stale name, parameter or field as `BINDING_DRIFT`, with the rename to follow.
 3. **Write Tests First (TDD)**:
    - Create or update the companion test file (e.g. `<component>.test.ts` or similar).
    - Mock all direct L2 dependencies using the signatures defined in their respective L3 `.interface.yaml` files.

package/dist/templates/variants/portal-shapes.yaml

@@ -6,8 +6,12 @@
   guidance: >-
     A Portal that authenticates, authorizes, validates or rate-limits inbound
     requests before dispatching them. Declare its inbound authentication in
-    `auth`, and hold NO verification logic in its own steps: CALL that logic —
-    read or pure Orchestrators, or one ingress Orchestrator when the admission
-    sequence carries its own policy — and return early on a rejection, before
-    anything is dispatched. Once a request is admitted, dispatch it as any
-    Portal does.
+    `auth`. Checking the credential `auth` declares — reading it from the
+    request and verifying it (a token comparison, a signature check) — is the
+    gateway's own admission step and may be a step of its own narrative. A
+    check that needs state or policy (the caller's grants, a quota, a
+    revocation list) is CALLED instead — read or pure Orchestrators, or one
+    ingress Orchestrator when the admission sequence carries its own policy.
+    Return early on a rejection, before anything is dispatched. Once a request
+    is admitted, dispatch it as any Portal does; writes still route through
+    Orchestrators.