@amsterdamdatalabs/enact-extensions 0.1.51 → 0.1.54

package/extensions/enact-repo/.agents/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "enact-repo",
-  "version": "0.1.5",
+  "version": "0.1.6",
   "description": "Baseline agent setup for any repository: the full Enact skill catalog plus guard, briefing, and code-review-graph hooks and MCP tooling, installed at repo scope.",
   "author": {
     "name": "amsterdamdatalabs"

package/extensions/enact-repo/skills/to-feature/SKILL.md

@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 Open a **Feature** on the board and give it a plan folder to live in.
 
-**A plan is a Feature, and a Feature is a directory** — `features/az<id>-<slug>/spec.md`, named for the work item it is. This skill creates that Feature and that directory; `to-workitems` later fills its `items/` with PBIs and Bugs parented under it. Where the repo carries a `plans/AGENTS.md`, it governs; otherwise follow the global `## Plans and work items` contract in your host's agent instructions.
+**A plan is a Feature, and a Feature is a directory** — `plans/features/az<id>-<slug>/spec.md`, named for the work item it is. This skill creates that Feature and that directory; `to-workitems` later fills its `items/` with PBIs and Bugs parented under it. Where the repo carries a `plans/AGENTS.md`, it governs; otherwise follow the global `## Plans and work items` contract in your host's agent instructions.
 
 Do NOT interview the user — synthesize what you already know from the conversation and the codebase.
 
@@ -72,7 +72,7 @@ workitem_create_or_update({
 
 ### 6. Record the id, then verify the link landed
 
-Create `features/az<id>-<slug>/` — named with the id the create call just returned, which is the only name it ever has — and write the drafted spec into its `spec.md` with `work_item:` set to that id and `epic:` carried through. Do this **immediately**, before anything else: a crash then leaves a folder that says what exists on the board, rather than a Feature nobody can trace back to a plan.
+Create `plans/features/az<id>-<slug>/` — named with the id the create call just returned, which is the only name it ever has — and write the drafted spec into its `spec.md` with `work_item:` set to that id and `epic:` carried through. Do this **immediately**, before anything else: a crash then leaves a folder that says what exists on the board, rather than a Feature nobody can trace back to a plan.
 
 Leave `items/` uncreated. A Feature whose items do not exist yet is the normal resting state of a fresh plan, not an unfinished one.
 

package/extensions/enact-repo/skills/to-feature/references/FEATURE-SPEC-TEMPLATE.md

@@ -1,6 +1,6 @@
 # The plan document
 
-`features/az<id>-<slug>/spec.md`. **This file IS the Feature** — the long form of its work
+`plans/features/az<id>-<slug>/spec.md`. **This file IS the Feature** — the long form of its work
 item, not a parallel copy. `## Problem` and `## Solution` are its Description; `## Acceptance
 criteria` is its Acceptance Criteria field. If the two ever differ, the board is lying.
 
@@ -52,11 +52,12 @@ Non-goals: [what a reader would wrongly assume is included]
 
 ## Items
 
-Order and dependencies. What each delivers lives in its own file under `items/`.
+Order and dependencies. Each row is the complete source for an item that does not have a file
+until `to-workitems` allocates its id.
 
-| # | Item | Work item | Predecessor |
-| --- | --- | --- | --- |
-| 1 | `az<id>-<slug>.md` | <id> | — |
+| # | Title | Item type | Delivers | Verification | Work item | Predecessor |
+| --- | --- | --- | --- | --- | --- | --- |
+| 1 | [the outcome this slice delivers] | pbi | [the complete vertical slice] | [a falsifiable check] |  | — |
 
 ## Verification
 

package/extensions/enact-repo/skills/to-workitems/SKILL.md

@@ -17,13 +17,13 @@ Put a plan's **backlog items** on the board.
 ## Do Not Use When
 
 - The plan has open decisions under `## Decisions` — resolve them first, or chart the effort with `wayfinder` if the destination itself is still unclear.
-- `epic:` or `feature:` is unset. **Stop and ask.** Never create an Epic or Feature to fill the gap: a typo must fail here, not silently spawn a duplicate. The server refuses a stray Epic outright, and refuses a wrong-*typed* parent for any creatable type — but a right-typed id can still be the **wrong** one, and nothing on the board catches that. Identity is on you.
+- `epic:` or `work_item:` is unset. **Stop and ask.** Those are the plan's Epic id and Feature id respectively. Never create an Epic or Feature to fill the gap: a typo must fail here, not silently spawn a duplicate. The server refuses a stray Epic outright, and refuses a wrong-*typed* parent for any creatable type — but a right-typed id can still be the **wrong** one, and nothing on the board catches that. Identity is on you.
 
 ## Process
 
 ### 1. Read the plan and check the board
 
-`workitem_list_or_get({ id: <feature>, raw: true })` and assert:
+`workitem_list_or_get({ id: <work_item>, raw: true })` and assert:
 
 - `fields['System.WorkItemType']` is `Feature`
 - `links.parent` is `epic`
@@ -65,14 +65,15 @@ In `## Items` order, predecessors first — that is what makes `predecessors` ex
 workitem_create_or_update({
   type: <item_type: pbi -> 'Product Backlog Item', bug -> 'Bug'>,
   title: <the item's title>,
-  description: <the body, per references/TICKET-TEMPLATES.md>,
-  parentId: <the plan's feature>,
+  description: <the row's Delivers plus its source plan and row, per references/TICKET-TEMPLATES.md>,
+  acceptanceCriteria: <the row's Verification, verbatim>,
+  parentId: <the plan's work_item>,
   predecessors: [<ids of the rows this one lists under Predecessor>],
   related: [<for a Bug: the id of the PBI it was found in>],
 })
 ```
 
-The body is the row's own what-it-delivers and verification, shaped by [references/TICKET-TEMPLATES.md](references/TICKET-TEMPLATES.md). It goes in on the create call — `description` is an advertised argument that becomes a `System.Description` field op, so there is no follow-up write and nothing to confirm afterwards.
+The row's delivery and source become `description`, shaped by [references/TICKET-TEMPLATES.md](references/TICKET-TEMPLATES.md). Its falsifiable verification becomes `acceptanceCriteria` verbatim. Both are advertised arguments and go on the create call, so the board receives the same fields as the row without a follow-up write.
 
 A Bug parents to the **Feature**, exactly as a PBI does, so `related` is the only way to record which item it was found while building.
 

package/extensions/enact-repo/skills/to-workitems/references/TICKET-TEMPLATES.md

@@ -2,22 +2,24 @@
 
 ## The work item's `description`
 
-Sent on the create call for every PBI and Bug. It is the item's own two sections — no more:
+Sent on the create call for every PBI and Bug. It carries what the row delivers and where that
+row came from:
 
 ```markdown
 ## What it delivers
 
 The end-to-end behaviour this makes work. Not a layer-by-layer list.
 
-## Verification
-
-The falsifiable check. A command and its expected result, not "tested".
-
 ## Source
 
 Plan: the Feature's `spec.md`, `## Items` row <n>.
 ```
 
+## The work item's `acceptanceCriteria`
+
+The row's `Verification` cell, verbatim: a falsifiable check with its expected result, not
+"tested". Send it as `acceptanceCriteria` on the same create call as `description`.
+
 ## The item file
 
 Written after the create call returns, because the file is named `az<work item id>-<slug>.md`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amsterdamdatalabs/enact-extensions",
-  "version": "0.1.51",
+  "version": "0.1.54",
   "description": "Create and validate Enact multi-platform plugin manifests",
   "license": "UNLICENSED",
   "type": "module",