@entelligentsia/forgecli 0.10.1 → 0.11.2

package/dist/forge-payload/meta/workflows/meta-sprint-intake.md

@@ -0,0 +1,76 @@
+---
+requirements:
+  reasoning: High
+  context: Medium
+  speed: Low
+deps:
+  personas: [product-manager]
+  skills: [architect, generic]
+  templates: [SPRINT_REQUIREMENTS_TEMPLATE, SPRINT_MANIFEST_TEMPLATE]
+  sub_workflows: []
+  kb_docs: [MASTER_INDEX.md, architecture/stack.md]
+  config_fields: [project.prefix, paths.engineering]
+---
+
+# 🌸 Meta-Workflow: Sprint Intake
+
+## Purpose
+
+Capture sprint requirements via a structured interview and document them for planning.
+
+## Algorithm
+
+```
+0. Project Orientation:
+   - Your current working directory is the project root.
+   - Forge config lives at `.forge/config.json` (relative to cwd); the `forge_config` MCP tool returns canonical values.
+   - Engineering knowledge lives under `engineering/` (relative to cwd) — `MASTER_INDEX.md`, `architecture/`, `business-domain/`, `sprints/`, `features/`.
+   - Paths in subsequent steps resolve against this cwd.
+
+1. Pre-flight Gate Check:
+   - Probe token reporting: if the host runtime exposes a `/cost` slash command
+     (Claude Code), invoke it; on any other runtime treat as unavailable and
+     proceed. Do NOT search for or invent a `cost-cli.cjs` — there is no such tool.
+   - If the probe succeeds → note for later (will use reported data)
+   - If the probe fails or is unavailable → note for later (will use estimates)
+
+2. Load Context:
+   - Read `engineering/MASTER_INDEX.md` (relative to cwd)
+   - Read any pending feature requests or bug reports under `engineering/`
+
+3. Requirements Interview:
+   - Conduct a structured interview with the user
+   - Capture: Objectives, Constraints, Deliverables, and Success Criteria
+   - Clarify ambiguous requirements through iterative questioning
+
+4. Document Requirements:
+   - Generate `engineering/sprints/<SPRINT_ID>/SPRINT_REQUIREMENTS.md`
+   - Map requirements to existing Features if applicable
+   - Ensure all deliverables are measurable and testable
+
+5. Finalize:
+   - Update sprint status via `node "$FORGE_ROOT/tools/store-cli.cjs" update-status sprint {sprintId} status planning`
+   - **Do NOT emit a phase event yourself.** The orchestrator (or kickoff handler) owns event emission — it composes the canonical event from runtime telemetry (model, provider, tokens, wall times) plus the SUMMARY you write in the next step. Subagents that call `store-cli emit` for phase events hallucinate runtime facts (see Plan 11 / Slice 2). Write the SUMMARY and return.
+```
+
+## Generation Instructions
+
+- **Persona Self-Load:** The generated workflow MUST begin by reading `.forge/personas/product-manager.md` as its first step (before any other tool use). This replaces the former inline `## Persona` section. The persona identity line (emoji, name, tagline) should be printed to stdout after reading the file.
+- **Workflow Structure:** The generated `sprint_intake.md` must follow the strict "Algorithm" block format.
+- **Context Isolation:** Forbid inline execution of requirement analysis; use the `Agent` tool for sub-tasks.
+- **Project Specifics:**
+  - Reference project-specific requirement templates.
+- **Token Reporting:** The generated workflow MUST mandate the following before returning:
+  1. Probe session token usage: invoke `/cost` if the host runtime supports it
+     (Claude Code only); on any other runtime treat as unavailable. Do NOT
+     shell out to a `cost-cli.cjs` — there is no such tool.
+  2. If the probe succeeds:
+     - Parse: `inputTokens`, `outputTokens`, `cacheReadTokens`, `cacheWriteTokens`, `estimatedCostUSD`.
+     - Add `"source": "reported"` to sidecar JSON.
+  3. If the probe fails or is unavailable:
+     - Set token fields to `null`: `"inputTokens": null, "outputTokens": null, "estimatedCostUSD": null`.
+     - Add `"source": "missing"` to sidecar JSON.
+     - Log: "Token data unavailable (cost probe failed). Backfill later via estimate-usage.cjs."
+  4. Write the usage sidecar via `node "$FORGE_ROOT/tools/store-cli.cjs" emit {sprintId} '{sidecar-json}' --sidecar`.
+  5. **NEVER skip sidecar write.** Always emit (reported or placeholder with nulls).
+- **Event Emission:** Ensure the "complete" event includes the `eventId` passed by the orchestrator.

package/dist/forge-payload/meta/workflows/meta-sprint-plan.md

@@ -0,0 +1,147 @@
+---
+requirements:
+  reasoning: High
+  context: Medium
+  speed: Low
+deps:
+  personas: [architect]
+  skills: [architect, generic]
+  templates: [SPRINT_MANIFEST_TEMPLATE, TASK_PROMPT_TEMPLATE]
+  sub_workflows: []
+  kb_docs: [MASTER_INDEX.md, architecture/stack.md]
+  config_fields: [project.prefix, paths.engineering]
+---
+
+# 🗻 Meta-Workflow: Sprint Plan
+
+## Purpose
+
+Break sprint requirements into a set of estimated tasks with a dependency graph.
+
+## Algorithm
+
+```
+0. Pre-flight Gate Check:
+   - Probe token reporting: if the host runtime exposes a `/cost` slash command
+     (Claude Code), invoke it; on any other runtime treat as unavailable. Do
+     NOT search for or invent a `cost-cli.cjs` — there is no such tool.
+   - If the probe succeeds → note for later (will use reported data)
+   - If the probe fails or is unavailable → note for later (will use estimates)
+
+1. Load Context:
+   - Query the store to orient on current project state before reading docs:
+     ```sh
+     node "$FORGE_ROOT/tools/store-cli.cjs" nlp "latest sprint"
+     node "$FORGE_ROOT/tools/store-cli.cjs" nlp "open bugs"
+     ```
+     Use results (titles, statuses, excerpts, file refs) to skip manual MASTER_INDEX.md navigation where sufficient.
+   - Read SPRINT_REQUIREMENTS.md
+   - Read architecture and domain docs
+   - Read the stack checklist
+
+2. Task Decomposition:
+   - Break requirements into atomic tasks
+   - Assign each task to a Feature (if applicable)
+   - Define clear acceptance criteria for each task
+   - Use the `ID-description` format (e.g., `FORGE-S05-agent-runtime-portability`) for sprint and task folders.
+
+3. Estimation and Sequencing:
+   - Estimate each task (S, M, L) based on complexity
+   - Define the dependency graph (which tasks must precede others)
+   - Identify the critical path
+
+4. Documentation:
+   - Write SPRINT_PLAN.md to `engineering/sprints/{sprintId}/SPRINT_PLAN.md`
+   - Create each task via `node "$FORGE_ROOT/tools/store-cli.cjs" write task '{task-json}'`.
+     If the command exits non-zero or the PreToolUse hook blocks the write:
+     parse the error, correct the JSON, and retry (see Store-Write Verification).
+     Do not proceed to the next task until this write succeeds.
+   - Update the sprint record with all new task IDs via `node "$FORGE_ROOT/tools/store-cli.cjs" write sprint '{updated-sprint-json}'` (the sprint JSON must include the complete `taskIds` array with all newly created task IDs).
+     If the command exits non-zero or the PreToolUse hook blocks the write:
+     parse the error, correct the JSON, and retry (see Store-Write Verification).
+     Do not proceed until this write succeeds.
+   - For each task, create its task folder and write TASK_PROMPT.md:
+     * Folder: `engineering/sprints/{sprintId}/{taskId}/`
+     * File: `TASK_PROMPT.md` — populate from `.forge/templates/TASK_PROMPT_TEMPLATE.md`
+       filling in title, objective, acceptance criteria, entities, DSL/CLI changes, and operational impact
+   - Update sprint status via `node "$FORGE_ROOT/tools/store-cli.cjs" update-status sprint {sprintId} status active`.
+     If the command exits non-zero, parse the error and retry
+     (see Store-Write Verification). Do not proceed until this write succeeds.
+
+5. Finalize:
+   - **Do NOT emit a phase event yourself.** The orchestrator (or kickoff handler) owns event emission — it composes the canonical event from runtime telemetry (model, provider, tokens, wall times) plus the SUMMARY you write in the next step. Subagents that call `store-cli emit` for phase events hallucinate runtime facts (see Plan 11 / Slice 2). Write the SUMMARY and return.
+```
+
+## Anti-Pattern Guard
+
+The generated workflow MUST include the following section verbatim, placed immediately
+after the Purpose heading and before the Algorithm block:
+
+```
+## Iron Laws
+
+- YOU MUST NOT write any code, pseudocode, or implementation sketch.
+- YOU MUST NOT produce a plan of your own before reading this workflow.
+- YOU MUST follow the Algorithm below step by step. Reading it is not optional.
+- If you have already read SPRINT_REQUIREMENTS.md and feel ready to decompose tasks:
+  stop. Return to step 1 of the Algorithm and proceed from there.
+```
+
+## Store-Write Verification
+
+Every write to the Forge store MUST succeed before the agent proceeds to the next
+step. Store writes include `store-cli` commands (`write`, `update-status`, `emit`)
+and direct `Write`/`Edit` tool calls against Forge-owned paths under
+`.forge/store/`.
+
+If a write is rejected — either by `store-cli` exiting non-zero or by the
+`PreToolUse` write-boundary hook blocking the call with exit code 2 — the agent
+MUST:
+
+1. **Parse the error.** Both `store-cli` and the write-boundary hook emit
+   structured messages naming the offending field and referencing the relevant
+   schema file (e.g. `forge/schemas/task.schema.json`). Read the error carefully
+   to identify which field is wrong and what the schema expects.
+2. **Correct the data.** Fix the JSON payload to satisfy the schema: add missing
+   required fields, fix type mismatches, remove undeclared properties, correct
+   enum values, etc. If the hook message mentions a schema file, read that file
+   to understand the full shape.
+3. **Retry the write.** Re-attempt the same store write with the corrected payload.
+4. **Repeat until success.** Do NOT advance past the current step, emit events,
+   or produce further artifacts until the write is confirmed successful.
+
+**Maximum retries: 3.** If the write still fails after 3 correction attempts,
+halt and escalate to the human. Include the original payload, the corrected
+payload, and all error messages in the escalation.
+
+**Do NOT** set `FORGE_SKIP_WRITE_VALIDATION=1` to bypass a schema error. That
+environment variable is reserved for emergency operator repair only.
+
+## Generation Instructions
+
+- **Persona Self-Load:** The generated workflow MUST begin by reading `.forge/personas/architect.md` as its first step (before any other tool use). This replaces the former inline `## Persona` section. The persona identity line (emoji, name, tagline) should be printed to stdout after reading the file.
+- **Workflow Structure:** The generated `sprint_plan.md` must follow the strict "Algorithm" block format.
+- **Context Isolation:** Forbid inline execution of task decomposition or estimation; use the `Agent` tool for sub-tasks.
+- **Project Specifics:**
+  - Use project-specific estimation guidelines.
+  - Reference project's task manifest schema.
+- **Token Reporting:** The generated workflow MUST mandate the following before returning:
+  1. Probe session token usage: invoke `/cost` if the host runtime supports it
+     (Claude Code only); on any other runtime treat as unavailable. Do NOT
+     shell out to a `cost-cli.cjs` — there is no such tool.
+  2. If the probe succeeds:
+     - Parse: `inputTokens`, `outputTokens`, `cacheReadTokens`, `cacheWriteTokens`, `estimatedCostUSD`.
+     - Add `"source": "reported"` to sidecar JSON.
+  3. If the probe fails or is unavailable:
+     - Set token fields to `null`: `"inputTokens": null, "outputTokens": null, "estimatedCostUSD": null`.
+     - Add `"source": "missing"` to sidecar JSON.
+     - Log: "Token data unavailable (cost probe failed). Backfill later via estimate-usage.cjs."
+  4. Write the usage sidecar via `node "$FORGE_ROOT/tools/store-cli.cjs" emit {sprintId} '{sidecar-json}' --sidecar`.
+  5. **NEVER skip sidecar write.** Always emit (reported or placeholder with nulls).
+- **Event Emission:** Ensure the "complete" event includes the `eventId` passed by the orchestrator.
+- **Store-Write Verification:** The generated workflow MUST include the "Store-Write
+  Verification" section verbatim. Every `store-cli write`, `store-cli update-status`,
+  and `store-cli emit` command in the Algorithm must be annotated with the
+  parse-correct-retry instruction: "If the command exits non-zero or the
+  PreToolUse hook blocks the write: parse the error, correct the JSON, and retry
+  (see Store-Write Verification). Do not proceed until this write succeeds."

package/dist/forge-payload/meta/workflows/meta-update-implementation.md

@@ -0,0 +1,76 @@
+---
+requirements:
+  reasoning: Medium
+  context: Medium
+  speed: Medium
+audience: subagent
+phase: update-impl
+context:
+  architecture: false
+  prior_summaries: delta
+  persona: summary
+  master_index: false
+  diff_mode: false
+deps:
+  personas: [engineer]
+  skills: [engineer, generic]
+  templates: [PROGRESS_TEMPLATE]
+  sub_workflows: [review_code]
+  kb_docs: [architecture/stack.md]
+  config_fields: [commands.test, paths.engineering]
+---
+
+# 🌱 Meta-Workflow: Update Implementation
+
+## Purpose
+
+Update the implementation of a task based on a "Revision Required" verdict from a review phase.
+
+## Iron Laws
+
+- Address every "Revision Required" item from the review artifact at the correct code location; do not paper over them with comments. If a finding is wrong, escalate rather than ignore.
+- Read `.forge/personas/engineer.md` first; print the persona identity line (emoji, name, tagline) to stdout before any other tool use.
+- All store I/O via `forge_store` (or `node "$FORGE_ROOT/tools/store-cli.cjs"`). Never edit `.forge/store/*.json` directly.
+
+## Store-Write Verification
+
+Every `forge_store` write MUST succeed before advancing. If `store-cli` exits
+non-zero or the `PreToolUse` write-boundary hook blocks the call (exit 2):
+
+1. Parse the structured error (names the offending field + schema file).
+2. Correct the JSON to satisfy the schema.
+3. Retry. Repeat up to 3 times.
+4. After 3 failures, halt and escalate with original payload, corrected payload, and all error messages.
+
+Never set `FORGE_SKIP_WRITE_VALIDATION=1` — operator-only emergency switch.
+
+## Algorithm
+
+```
+1. Load Context:
+   - Read current implementation (code)
+   - Read the review artifact (CODE_REVIEW.md or VALIDATION_REPORT.md)
+   - Read the approved PLAN.md
+
+2. Analysis:
+   - Map the "Revision Required" items to specific code locations
+   - Determine if the required changes necessitate a plan update
+
+3. Implementation:
+   - Apply the necessary fixes/changes
+   - Verify the changes using the **resolved test command** from `commands.test` in `.forge/config.json` (i.e. `` `${commands.test}` ``, e.g. `.venv/bin/python -m pytest`). Template placeholder: {{TEST_COMMAND}}. Do NOT invoke bare `python` / `python3` — the project interpreter is rarely on `$PATH`.
+   - Update PROGRESS.md with a summary of the revisions
+
+4. Finalize:
+   - Update task status via `node "$FORGE_ROOT/tools/store-cli.cjs" update-status task {taskId} status implemented`
+   - **Do NOT emit a phase event yourself.** The orchestrator (or kickoff handler) owns event emission — it composes the canonical event from runtime telemetry (model, provider, tokens, wall times) plus the SUMMARY you write in the next step. Subagents that call `store-cli emit` for phase events hallucinate runtime facts (see Plan 11 / Slice 2). Write the SUMMARY and return.
+```
+
+## Generation Instructions
+
+- **Workflow Structure:** The generated `update_implementation.md` must follow the strict "Algorithm" block format.
+- **Context Isolation:** Forbid inline execution of fix logic; use the `Agent` tool for sub-tasks.
+- **Project Specifics:**
+  - Reference project-specific verification commands.
+- **Token Reporting:** See `_fragments/finalize.md` — wire via `file_ref:`.
+- **Event Emission:** Ensure the "complete" event includes the `eventId` passed by the orchestrator.

package/dist/forge-payload/meta/workflows/meta-update-plan.md

@@ -0,0 +1,76 @@
+---
+requirements:
+  reasoning: Medium
+  context: Medium
+  speed: Medium
+audience: subagent
+phase: update-plan
+context:
+  architecture: false
+  prior_summaries: delta
+  persona: summary
+  master_index: false
+  diff_mode: false
+deps:
+  personas: [architect]
+  skills: [architect, generic]
+  templates: [PLAN_TEMPLATE]
+  sub_workflows: [review_plan]
+  kb_docs: [architecture/stack.md]
+  config_fields: [paths.engineering]
+---
+
+# 🌱 Meta-Workflow: Update Plan
+
+## Purpose
+
+Update the implementation plan of a task based on a "Revision Required" verdict from the plan review phase.
+
+## Iron Laws
+
+- Address every numbered finding in the review artifact. Do not silently drop items; if a finding is wrong, note the reason in the revised plan rather than ignoring it.
+- Read `.forge/personas/architect.md` first; print the persona identity line (emoji, name, tagline) to stdout before any other tool use.
+- All store I/O via `forge_store` (or `node "$FORGE_ROOT/tools/store-cli.cjs"`). Never edit `.forge/store/*.json` directly.
+
+## Store-Write Verification
+
+Every `forge_store` write MUST succeed before advancing. If `store-cli` exits
+non-zero or the `PreToolUse` write-boundary hook blocks the call (exit 2):
+
+1. Parse the structured error (names the offending field + schema file).
+2. Correct the JSON to satisfy the schema.
+3. Retry. Repeat up to 3 times.
+4. After 3 failures, halt and escalate with original payload, corrected payload, and all error messages.
+
+Never set `FORGE_SKIP_WRITE_VALIDATION=1` — operator-only emergency switch.
+
+## Algorithm
+
+```
+1. Load Context:
+   - Read the original task prompt
+   - Read the current PLAN.md
+   - Read the review artifact (PLAN_REVIEW.md)
+
+2. Analysis:
+   - Review the numbered, actionable items in the review artifact
+   - Determine where the plan was insufficient or incorrect
+
+3. Revision:
+   - Update PLAN.md to address all review findings
+   - Ensure the revised plan remains aligned with the task prompt
+   - Update the "Operational Impact" or "Testing Strategy" if the revision changed them
+
+4. Finalize:
+   - Update task status via `node "$FORGE_ROOT/tools/store-cli.cjs" update-status task {taskId} status planned`
+   - **Do NOT emit a phase event yourself.** The orchestrator (or kickoff handler) owns event emission — it composes the canonical event from runtime telemetry (model, provider, tokens, wall times) plus the SUMMARY you write in the next step. Subagents that call `store-cli emit` for phase events hallucinate runtime facts (see Plan 11 / Slice 2). Write the SUMMARY and return.
+```
+
+## Generation Instructions
+
+- **Workflow Structure:** The generated `update_plan.md` must follow the strict "Algorithm" block format.
+- **Context Isolation:** Forbid inline execution of plan revision; use the `Agent` tool for sub-tasks.
+- **Project Specifics:**
+  - Reference the project's plan template.
+- **Token Reporting:** See `_fragments/finalize.md` — wire via `file_ref:`.
+- **Event Emission:** Ensure the "complete" event includes the `eventId` passed by the orchestrator.

package/dist/forge-payload/meta/workflows/meta-validate.md

@@ -0,0 +1,111 @@
+---
+requirements:
+  reasoning: High
+  context: Medium
+  speed: Low
+audience: subagent
+phase: validate
+context:
+  architecture: false
+  prior_summaries: none
+  persona: summary
+  master_index: false
+  diff_mode: true
+deps:
+  personas: [qa-engineer]
+  skills: [qa-engineer, generic]
+  templates: []
+  sub_workflows: []
+  kb_docs: [architecture/stack.md]
+  config_fields: [commands.test, paths.engineering]
+---
+
+# 🍵 Meta-Workflow: Validate Task
+
+## Purpose
+
+The Supervisor performs a final validation of the implementation against the acceptance criteria and the technical spec.
+
+## Iron Laws
+
+- Validate against the acceptance criteria as written; do not soften, expand, or reinterpret them. The validator's job is to catch what the implementer optimistically considered "done".
+- Read `.forge/personas/qa-engineer.md` first; print the persona identity line (emoji, name, tagline) to stdout before any other tool use.
+- All store I/O via `forge_store` (or `node "$FORGE_ROOT/tools/store-cli.cjs"`). Never edit `.forge/store/*.json` directly.
+
+## Store-Write Verification
+
+Every `forge_store` write MUST succeed before advancing. If `store-cli` exits
+non-zero or the `PreToolUse` write-boundary hook blocks the call (exit 2):
+
+1. Parse the structured error (names the offending field + schema file).
+2. Correct the JSON to satisfy the schema.
+3. Retry. Repeat up to 3 times.
+4. After 3 failures, halt and escalate with original payload, corrected payload, and all error messages.
+
+Never set `FORGE_SKIP_WRITE_VALIDATION=1` — operator-only emergency switch.
+
+## Algorithm
+
+```
+
+0. Pre-flight Gate Check:
+   - Resolve FORGE_ROOT (`node -e "console.log(require('./.forge/config.json').paths.forgeRoot)"`).
+   - Run: `node "$FORGE_ROOT/tools/preflight-gate.cjs" --phase validate --task {taskId}`
+   - Exit 1 (gate failed) → print stderr and HALT. Do not proceed; do not attempt to produce the artifact.
+   - Exit 2 (misconfiguration) → print stderr and HALT.
+   - Exit 0 → continue.
+
+1. Load Context:
+   - Read task prompt
+   - Read approved PLAN.md
+   - Read the implementation
+   - Read PROGRESS.md
+
+2. Validation:
+   - Execute the "Acceptance Criteria" checklist from the plan
+   - Verify that all technical constraints (e.g., performance, security) are met
+   - Check for any regressions in related functionality
+   - When re-running the test suite, use the **resolved test command** from `commands.test` in `.forge/config.json` (i.e. `` `${commands.test}` ``, e.g. `.venv/bin/python -m pytest`). Template placeholder: {{TEST_COMMAND}}. Do NOT invoke bare `python` / `python3` — the project interpreter is rarely on `$PATH`.
+
+3. Verdict:
+   - Write VALIDATION_REPORT.md using the format:
+     **Verdict:** [Approved | Revision Required]
+     - If Revision Required: list the failed criteria and required fixes
+     - If Approved: confirm the task is validated
+
+4. Finalize:
+   - Update task status via `node "$FORGE_ROOT/tools/store-cli.cjs" update-status task {taskId} status review-approved` (if Approved) or `node "$FORGE_ROOT/tools/store-cli.cjs" update-status task {taskId} status code-revision-required` (if Revision Required)
+   - **Do NOT emit a phase event yourself.** The orchestrator owns event emission — it composes the canonical event from runtime telemetry (model, provider, tokens, wall times) plus the SUMMARY you write in the next step. Subagents that call `store-cli emit` for phase events hallucinate runtime facts (see Plan 11 / Slice 2). Write the SUMMARY and return.
+
+5. Emit Summary Sidecar:
+   - Write `VALIDATION-SUMMARY.json` to the task directory with the following shape:
+     ```json
+     {
+       "objective":   "<one sentence — what acceptance criteria were validated>",
+       "findings":    ["<up to 12 bullets, 200 chars each — pass/fail per criterion>"],
+       "verdict":     "<approved | revision>",
+       "written_at":  "<current ISO 8601 timestamp>",
+       "artifact_ref":"VALIDATION_REPORT.md"
+     }
+     ```
+   - Call:
+     ```
+     node "$FORGE_ROOT/tools/store-cli.cjs" set-summary {task_id} validation \
+       engineering/sprints/{sprint}/{task}/VALIDATION-SUMMARY.json
+     ```
+   - If set-summary exits non-zero, fix the sidecar JSON and retry. Do not proceed without a valid summary.
+```
+
+## Friction Emit
+Emit `type:friction` `{workflow:validate, persona:qa-engineer, issue}` per `_fragments/friction-emit.md`.
+
+## Generation Instructions
+
+- **Workflow Structure:** The generated `validate_task.md` must follow the strict "Algorithm" block format.
+- **Verdict Detection:** The generated workflow MUST enforce the strict `**Verdict:** [Approved | Revision Required]` format.
+- **Context Isolation:** Forbid inline execution of validation tests; use the `Agent` tool for sub-tasks.
+- **Project Specifics:**
+  - Reference project-specific validation tools or smoke tests.
+- **Token Reporting:** See `_fragments/finalize.md` — wire via `file_ref:`.
+- **Diff-mode:** Generated workflow MUST include the diff-first read mode instruction (see plan PLAN.md A6).
+- **Event Emission:** Ensure the "complete" event includes the `eventId` passed by the orchestrator.