fix(ci): correct image digest separator

.wave/prompts/implement/create-pr.md

@@ -0,0 +1,131 @@
+You are creating a {{ forge.pr_term }} for the implemented issue.
+
+Input: {{ input }}
+
+## Working Directory
+
+You are running in an **isolated git worktree** shared with previous pipeline steps.
+Your working directory IS the project root. The feature branch was created by the
+plan step and is already checked out. All git operations here are isolated from
+the main working tree.
+
+Read the issue assessment artifact to find the issue number, repository, branch name, and issue URL.
+
+## SAFETY: Do NOT Modify the Working Tree
+
+This step MUST NOT run `git checkout`, `git stash`, or any command that changes
+the current branch or working tree state. The branch already exists from the
+implement step — just push it and create the {{ forge.pr_term }}.
+
+## Instructions
+
+### Step 1: Load Context
+
+From the issue assessment artifact, extract:
+- Issue number and title
+- Repository (`owner/repo`)
+- Branch name
+- Issue URL
+
+### Step 2: Push the Branch
+
+Push the feature branch. If SSH push fails, retry with HTTPS:
+
+```bash
+git push -u origin <BRANCH_NAME> || GIT_SSH_COMMAND="ssh -F /dev/null" git push -u origin <BRANCH_NAME>
+```
+
+### Step 3: Create {{ forge.pr_term }}
+
+Use the appropriate CLI for your platform ({{ forge.type }}) to create the {{ forge.pr_term }}.
+The description MUST include `Related to #<NUMBER>` to link the issue (without auto-closing it when the PR is closed without merge).
+
+**For GitHub** (`gh`):
+```bash
+gh pr create --repo <OWNER/REPO> --head <BRANCH_NAME> --title "<concise title>" --body "$(cat <<'EOF'
+## Summary
+<3-5 bullet points describing the changes>
+
+Related to #<ISSUE_NUMBER>
+
+## Changes
+<list of key files changed and why>
+
+## Test Plan
+<how the changes were validated>
+EOF
+)"
+```
+
+**For GitLab** (`glab`):
+```bash
+cat > /tmp/mr-body.md <<'EOF'
+## Summary
+<3-5 bullet points describing the changes>
+
+Related to #<ISSUE_NUMBER>
+
+## Changes
+<list of key files changed and why>
+
+## Test Plan
+<how the changes were validated>
+EOF
+glab mr create --repo <OWNER/REPO> --source-branch <BRANCH_NAME> --target-branch main --title '<concise title>' --description "$(cat /tmp/mr-body.md)"
+```
+
+**For Bitbucket** (REST API):
+```bash
+cat > /tmp/bb-payload.json << 'PRBODY'
+{
+  "title": "PR title",
+  "description": "PR description\n\nRelated to #NUMBER",
+  "source": {"branch": {"name": "BRANCH_NAME"}},
+  "destination": {"branch": {"name": "main"}},
+  "close_source_branch": true
+}
+PRBODY
+
+curl -s -X POST -H "Authorization: Bearer $BB_TOKEN" -H "Content-Type: application/json" \
+  -d @/tmp/bb-payload.json \
+  "https://api.bitbucket.org/2.0/repositories/WORKSPACE/REPO/pullrequests" \
+  | jq '{id, url: .links.html.href}'
+```
+
+**For Gitea** (`tea`):
+```bash
+cat > /tmp/pr-body.md <<'EOF'
+## Summary
+<3-5 bullet points describing the changes>
+
+Related to #<ISSUE_NUMBER>
+
+## Changes
+<list of key files changed and why>
+
+## Test Plan
+<how the changes were validated>
+EOF
+tea pulls create --repo <OWNER/REPO> --head <BRANCH_NAME> --base main --title '<concise title>' --description "$(cat /tmp/pr-body.md)"
+```
+
+### Step 4: Request Review (Best-Effort)
+
+After the {{ forge.pr_term }} is created, attempt to add a reviewer. This is a best-effort
+operation — if it fails, the {{ forge.pr_term }} is still created successfully.
+
+**For GitHub**: `gh pr edit --add-reviewer "copilot"`
+**For GitLab**: `glab mr update <MR_NUMBER> --reviewer "<username>"`
+**For Bitbucket**: Update PR via REST API with reviewers
+**For Gitea**: Skip (not directly supported by tea CLI)
+
+## CONSTRAINTS
+
+- Do NOT spawn Task subagents — work directly in the main context
+- Do NOT run `git checkout`, `git stash`, or any branch-switching commands
+- The {{ forge.pr_term }} description MUST contain `Related to #<NUMBER>` to link to the issue
+- Do NOT include Co-Authored-By or AI attribution in commits
+
+## Output
+
+Produce a JSON status report matching the injected output schema.

.wave/prompts/implement/fetch-assess.md

@@ -0,0 +1,99 @@
+You are fetching an issue and assessing whether it has enough detail to implement.
+
+Input: {{ input }}
+
+The input format is `owner/repo number` (e.g. `re-cinq/wave 42`).
+
+## Working Directory
+
+You are running in an isolated Wave workspace. The `{{ forge.cli_tool }}` CLI works from any
+directory when using the `--repo` flag, so no directory change is needed.
+
+## Instructions
+
+### Step 1: Parse Input
+
+Extract the repository (`owner/repo`) and issue number from the input string.
+
+### Step 2: Fetch Issue
+
+Use the appropriate CLI for your platform ({{ forge.type }}) to fetch the issue with full details.
+
+**For GitHub** (`gh`):
+```bash
+gh issue view <NUMBER> --repo <OWNER/REPO> --json number,title,body,url,labels,state,author,comments
+```
+
+**For GitLab** (`glab`):
+```bash
+glab issue view <NUMBER> --repo <OWNER/REPO> --output json
+```
+
+**For Bitbucket** (REST API):
+```bash
+curl -s -H "Authorization: Bearer $BB_TOKEN" \
+  "https://api.bitbucket.org/2.0/repositories/WORKSPACE/REPO/issues/NUMBER" \
+  | jq '{id, title, content: .content.raw, state, kind, reporter: .reporter.display_name, created_on, url: .links.html.href}'
+```
+Also fetch comments:
+```bash
+curl -s -H "Authorization: Bearer $BB_TOKEN" \
+  "https://api.bitbucket.org/2.0/repositories/WORKSPACE/REPO/issues/NUMBER/comments" \
+  | jq '[.values[] | {id, content: .content.raw, user: .user.display_name, created_on}]'
+```
+
+**For Gitea** (`tea`):
+```bash
+tea issues view <NUMBER> --repo <OWNER/REPO> --output json
+```
+
+### Step 3: Assess Implementability
+
+Evaluate the issue against these criteria:
+
+1. **Clear description**: Does the issue describe what needs to change? (not just "X is broken")
+2. **Sufficient context**: Can you identify which code/files are affected?
+3. **Testable outcome**: Are there acceptance criteria, or can you infer them from the description?
+
+Score the issue 0-100:
+- **80-100**: Well-specified, clear requirements, acceptance criteria present
+- **60-79**: Adequate detail, some inference needed but feasible
+- **40-59**: Marginal — missing key details but core intent is clear
+- **0-39**: Too vague to implement — set `implementable` to `false`
+
+### Step 4: Determine Skip Steps
+
+Based on the issue quality, decide which speckit steps can be skipped:
+- Issues with detailed specs can skip `specify`, `clarify`, `checklist`, `analyze`
+- Issues with moderate detail might skip `specify` and `clarify` only
+- Vague issues should skip nothing (but those should fail the assessment)
+
+### Step 5: Generate Branch Name
+
+Create a branch name using the pattern `<NNN>-<short-name>` where:
+- `<NNN>` is the issue number zero-padded to 3 digits
+- `<short-name>` is 2-3 words from the issue title, kebab-case
+
+### Step 6: Assess Complexity
+
+Estimate implementation complexity:
+- **trivial**: Single file change, obvious fix (typo, config tweak)
+- **simple**: 1-3 files, straightforward logic change
+- **medium**: 3-10 files, new feature with tests
+- **complex**: 10+ files, architectural changes, cross-cutting concerns
+
+## CRITICAL: Implementability Gate
+
+If the issue does NOT have enough detail to implement:
+- Set `"implementable": false` in the output
+- This will cause the contract validation to fail, aborting the pipeline
+- Include `missing_info` listing what specific information is needed
+- Include a `summary` explaining why the issue cannot be implemented as-is
+
+If the issue IS implementable:
+- Set `"implementable": true`
+
+## CONSTRAINTS
+
+- Do NOT spawn Task subagents — work directly in the main context
+- Do NOT modify the issue — this is read-only assessment

.wave/prompts/implement/implement.md

@@ -0,0 +1,92 @@
+You are implementing an issue according to the plan and task breakdown.
+
+Input: {{ input }}
+
+## Working Directory
+
+You are running in an **isolated git worktree** shared with previous pipeline steps.
+Your working directory IS the project root. The feature branch was created by the
+plan step and is already checked out. All git operations here are isolated from
+the main working tree.
+
+## Instructions
+
+### Step 1: Load Context
+
+1. Get the issue details and branch name from the issue assessment artifact
+2. Get the task breakdown, file changes, and feature directory from the plan artifact
+
+### Step 2: Read Plan Files
+
+Navigate to the feature directory and read:
+- `spec.md` — the full specification
+- `plan.md` — the implementation plan
+- `tasks.md` — the phased task breakdown
+
+### Step 3: Execute Implementation
+
+Follow the task breakdown phase by phase:
+
+**Setup first**: Initialize project structure, dependencies, configuration
+
+**Tests before code (TDD)**:
+- Write tests that define expected behavior
+- Run tests to confirm they fail for the right reason
+- Implement the code to make tests pass
+
+**Core development**: Implement the changes specified in the plan
+
+**Integration**: Wire components together, update imports, middleware
+
+**Polish**: Edge cases, error handling, documentation updates
+
+### Step 4: Validate Between Phases
+
+After each phase, run:
+```bash
+{{ project.test_command }}
+```
+
+If tests fail, fix the issue before proceeding to the next phase.
+
+### Step 5: Mark Completed Tasks
+
+As you complete each task, mark it as `[X]` in `tasks.md`.
+
+### Step 6: Final Validation
+
+After all tasks are complete:
+1. Run `{{ project.test_command }}` one final time
+2. Verify all tasks in `tasks.md` are marked complete
+3. Stage and commit all changes — YOU MUST run the git reset to exclude Wave internals:
+   ```bash
+   git add -A
+   git reset HEAD -- .wave/artifacts/ .wave/output/ .claude/ CLAUDE.md 2>/dev/null || true
+   git diff --cached --name-only | head -20  # verify no .wave/artifacts, .wave/output, .claude, or CLAUDE.md
+   git commit -m "feat: implement #<ISSUE_NUMBER> — <short description>"
+   ```
+
+   CRITICAL: Never use `Closes #N`, `Fixes #N`, or `Resolves #N` in commit messages — these auto-close issues on merge. Use the issue number without closing keywords as shown above.
+   CRITICAL: Never commit `.claude/settings.json`, `CLAUDE.md`, `.wave/artifacts/`, or `.wave/output/`.
+   These are Wave-managed files. The `specs/` directory IS allowed.
+
+Commit changes to the worktree branch.
+
+## Agent Usage
+
+Maximize parallelism with up to 6 Task agents for independent work:
+- Agents 1-2: Setup and foundational tasks (Phase 1-2)
+- Agents 3-4: Core implementation tasks (parallelizable [P] tasks)
+- Agent 5: Test writing and validation
+- Agent 6: Integration and polish tasks
+
+Coordinate agents to respect task dependencies:
+- Sequential tasks (no [P] marker) must complete before dependents start
+- Parallel tasks [P] affecting different files can run simultaneously
+- Run test validation between phases
+
+## Error Handling
+
+- If a task fails, halt dependent tasks but continue independent ones
+- Provide clear error context for debugging
+- If tests fail, fix the issue before proceeding to the next phase

.wave/prompts/implement/plan.md

@@ -0,0 +1,91 @@
+You are creating an implementation plan for an issue.
+
+Input: {{ input }}
+
+## Working Directory
+
+You are running in an **isolated git worktree** checked out at `main` (detached HEAD).
+Your working directory IS the project root. All git operations here are isolated
+from the main working tree and will not affect it.
+
+Create a feature branch from this clean starting point.
+
+## Instructions
+
+### Step 1: Read Assessment
+
+From the issue assessment artifact, extract:
+- Issue number, title, body, and repository
+- Branch name from the assessment
+- Complexity estimate
+- Which speckit steps were skipped
+
+### Step 2: Create Feature Branch
+
+Create a feature branch using the branch name from the assessment:
+
+```bash
+git checkout -b <BRANCH_NAME>
+```
+
+If the branch already exists (e.g. from a resume), check it out instead:
+```bash
+git checkout <BRANCH_NAME>
+```
+
+### Step 3: Write Spec from Issue
+
+In the feature directory (e.g. `specs/<BRANCH_NAME>/`), create `spec.md` with:
+- Issue title as heading
+- Full issue body
+- Labels and metadata
+- Any acceptance criteria extracted from the issue
+- Link back to the original issue URL
+
+### Step 4: Create Implementation Plan
+
+Write `plan.md` in the feature directory with:
+
+1. **Objective**: What the issue asks for (1-2 sentences)
+2. **Approach**: High-level strategy
+3. **File Mapping**: Which files need to be created/modified/deleted
+4. **Architecture Decisions**: Any design choices made
+5. **Risks**: Potential issues and mitigations
+6. **Testing Strategy**: What tests are needed
+
+### Step 5: Create Task Breakdown
+
+Write `tasks.md` in the feature directory with a phased breakdown:
+
+```markdown
+# Tasks
+
+## Phase 1: Setup
+- [ ] Task 1.1: Description
+- [ ] Task 1.2: Description
+
+## Phase 2: Core Implementation
+- [ ] Task 2.1: Description [P] (parallelizable)
+- [ ] Task 2.2: Description [P]
+
+## Phase 3: Testing
+- [ ] Task 3.1: Write unit tests
+- [ ] Task 3.2: Write integration tests
+
+## Phase 4: Polish
+- [ ] Task 4.1: Documentation updates
+- [ ] Task 4.2: Final validation
+```
+
+Mark parallelizable tasks with `[P]`.
+
+## CONSTRAINTS
+
+- Do NOT spawn Task subagents — work directly in the main context
+- Do NOT start implementation — only planning in this step
+- Do NOT use WebSearch — all information is in the issue and codebase
+- Do NOT create files or directories under `.wave/artifacts/` — that path is managed by the pipeline orchestrator
+
+## Output
+
+Produce a JSON status report matching the injected output schema.