@open-mercato/cli 0.6.7 → 0.6.8-canary.319.1.5b4be4bc52

package/dist/agentic/shared/ai/skills/om-implement-spec/references/planning-and-progress.md

@@ -0,0 +1,40 @@
+# Interactive Planning and Progress
+
+Derive the local execution plan from the resolved spec's approved implementation phases. This is a focused delivery plan, not a second design document.
+
+## Plan contract
+
+Present these fields in order:
+
+1. **Goal** — the selected phases' observable outcome in one sentence.
+2. **Scope** — selected phases, acceptance IDs, affected modules/packages, and real call sites.
+3. **Non-goals** — later phases and adjacent work that remain untouched.
+4. **Source doc:** `{SPEC_PATH}`.
+5. **Phase execution** — dependencies, ordered slices, owned files, routed guides/skills, closest references, BC/schema surfaces, test oracles, validation commands, and exit gates.
+6. **Risks** — only concrete rewrite, compatibility, data, security, or validation risks.
+
+Present the complete plan to the user before coding and wait for confirmation. If the user changes phase selection or scope, rebuild and re-present the affected plan instead of silently carrying stale assumptions.
+
+## Phase state and progress
+
+Only one phase may be `in_progress`; all dependencies must be `verified`. Add or update the resolved spec's `## Implementation Status` section:
+
+```markdown
+## Implementation Status
+
+Source doc: .ai/specs/{spec}.md
+
+| Phase | State | Dependencies | Acceptance IDs | Focused validation | Exit gate |
+|---|---|---|---|---|---|
+| Phase 1 — {name} | in_progress | none | AC-1, AC-2 | `{command}` | {observable gate} |
+| Phase 2 — {name} | pending | Phase 1 | AC-3 | `{command}` | {observable gate} |
+
+### Phase 1 progress
+
+- [x] {slice}: {files/real call sites} — `{command}` passed
+- [ ] {remaining slice}: {acceptance IDs and oracle}
+```
+
+After every slice, record changed areas, acceptance evidence, the exact focused command/result, and remaining work. Mark a phase `verified` only after `phases-and-gates.md` permits it. A partial or blocked phase stays `in_progress`, and later phases stay `pending`.
+
+Before moving to the next selected phase, show the completed phase evidence and ask to continue unless the user approved the whole selected sequence when confirming the plan. Do not create a separate autonomous run plan, branch, commit, or PR unless the user explicitly invokes the corresponding delivery workflow.

package/dist/agentic/shared/ai/skills/om-implement-spec/references/report-templates.md

@@ -0,0 +1,27 @@
+# Interactive Implement-Spec Report Templates
+
+Use this structure for complete, partial, and blocked local runs. Write full sentences that explain why each state was reached; do not compress the report into a key/value log.
+
+```markdown
+## 🎯 om-implement-spec — {spec title or slug}
+
+**Outcome:** {✅ selected phases implemented and verified | 🔁 partial | ⛔ blocked} — {what was delivered or what stopped and why}
+**📝 Spec:** `{repo-relative spec path}` — {how it was resolved and what selected phases cover}
+**Selected phases:** {phase IDs/names} — {why these were the confirmed boundary}
+
+### 📋 Plan & progress
+{Summarize the confirmed goal, scope, non-goals, completed slices/acceptance IDs, current phase states, and remaining work. Name where Implementation Status was updated.}
+
+### 🧪 Validation & 🔍 review
+{List exact focused and configured commands with results, integration paths exercised, the om-code-review verdict, follow-up fixes/revalidation, and any honest blocker.}
+
+### 📸 UI verification
+{Describe affected routes/states/themes/widths/keyboard flows exercised and local evidence, `UI: n/a` with a reason, or the missing verification that keeps the phase open.}
+
+### {✅ Done | 🔁 Next | ⛔ Blocked}
+{Complete: what is ready for the user's next workflow. Partial: the next pending slice/phase and the confirmation needed. Blocked: the exact decision or failing gate required to resume.}
+
+Spec: <repo-relative spec path>
+```
+
+The final `Spec:` line is always present, exact, undecorated, and last so a later workflow can consume it. This local interactive skill must never emit `PR:` or `Issue:` reference lines or claim branch/tracker state; those belong to PR automation skills. If the user separately asks for a PR, finish this report first and hand the exact `Spec:` reference to `om-auto-implement-spec` or the requested delivery workflow.

package/dist/agentic/shared/ai/skills/om-implement-spec/references/spec-resolution.md

@@ -0,0 +1,24 @@
+# Spec Resolution
+
+Resolve the user's reference before readiness analysis or planning. The first unambiguous match wins.
+
+1. **Path** — use an existing repository-relative Markdown file directly.
+2. **Name/title** — search the configured specs directory (`paths.specs`, default `.ai/specs`) case-insensitively by filename with or without its date prefix/extension, then by the document's first `# Title`. Use the newest dated file only when the title match is unambiguous.
+3. **Issue** — for a numeric reference and an available configured tracker, use its read-only issue operation and scan the body/comments for repository-relative spec paths. Do not mutate the issue.
+4. **Spec PR** — when the numeric issue lookup does not resolve a spec, use the tracker's read-only PR operation. Accept a spec path only when that file is already present locally. Do not fetch, check out, update, or implement on a spec PR branch; ask the user to materialize/merge it locally or use `om-auto-implement-spec` for PR delivery.
+
+Record the repository-relative path as `SPEC_PATH`. Validate that the file has an `## Implementation Plan` or `## Phasing` section. A found spec without one returns to `om-spec-writing` as not implementation-ready.
+
+If several candidates remain, stop and let the user select one. If no candidate exists, report:
+
+```text
+Status: blocked
+Spec not found for "{spec}".
+Searched: path, configured specs-directory name/title match, and read-only issue/spec-PR references when a tracker was available.
+Closest candidates:
+- {path} — {title}
+- …
+Next: pass an exact path, or create/revise the spec with om-spec-writing "{spec}".
+```
+
+This local resolver performs no tracker writes and makes no branch, commit, or PR claim.