@eventmodelers/cli 1.0.96 → 1.0.98

package/stacks/react/templates/build-kit/CLAUDE.md

@@ -32,12 +32,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

package/stacks/react/templates/build-kit/lib/backend-prompt.md

@@ -40,14 +40,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set in step 5), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

package/stacks/react/templates/build-kit/lib/prompt.md

@@ -52,7 +52,7 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified
@@ -93,14 +93,7 @@ After completing a task, remove it from the array and write the updated array ba
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

package/stacks/supabase/templates/build-kit/CLAUDE.md

@@ -37,12 +37,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

package/stacks/supabase/templates/build-kit/lib/backend-prompt.md

@@ -44,14 +44,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

package/stacks/supabase/templates/build-kit/lib/prompt.md

@@ -48,13 +48,13 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Webhook** — `sliceType === "WEBHOOK"` → invoke `/build-webhook`

package/stacks/supabase-react/templates/build-kit/CLAUDE.md

@@ -91,12 +91,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 **Exception: a missing `apiEndpoint`** (no backend endpoint/table decided yet) is a partial version of
 this — flag it, but don't fully stop. `build-state-change`/`build-state-view` Step 1 cover the exact

package/stacks/supabase-react/templates/build-kit/lib/backend-prompt.md

@@ -40,14 +40,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set in step 5), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

package/stacks/supabase-react/templates/build-kit/lib/prompt.md

@@ -52,7 +52,7 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from `sliceType` in the slice.json:
    - **`STATE_CHANGE`** → invoke `/build-state-change`
@@ -95,14 +95,7 @@ After completing a task, remove it from the array and write the updated array ba
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 **Exception: a missing `apiEndpoint`** (no backend endpoint/table decided yet) is a partial version of
 this — flag it, but don't fully stop. `build-state-change`/`build-state-view` Step 1 cover the exact

package/stacks/umadb/templates/build-kit/CLAUDE.md

@@ -48,12 +48,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

package/stacks/umadb/templates/build-kit/lib/backend-prompt.md

@@ -50,14 +50,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

package/stacks/umadb/templates/build-kit/lib/prompt.md

@@ -48,13 +48,13 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified

package/stacks/modeling-kit/templates/.claude/settings.local.json

@@ -1,13 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Skill(connect)",
-      "Bash(curl *)",
-      "Bash(python3 -c \"import uuid; print\\(uuid.uuid4\\(\\)\\)\")",
-      "Bash(python3 -c ' *)",
-      "Read(//tmp/**)",
-      "Bash(python3 -m json.tool)",
-      "Bash(npm run *)"
-    ]
-  }
-}