fix(implement-issues): configured deploy is a mandatory gate — skipped deploy = failed pass; stories touching deploy_paths carry a deployment AC #2

New issue

Closed

opened 2026-07-05 18:10:30 +00:00 by ksamaschke · 0 comments

ksamaschke commented

2026-07-05 18:10:30 +00:00

Owner

Context

2026-07-05, fritz-ai-local: an implement-issues pass merged changes matching the project's configured deploy_paths (hooks/**) and ended WITHOUT running the configured deploy command. The live Docker service kept running the old version (1.3.102 vs merged 1.3.105) until a human noticed the drift and ordered a manual rebuild. The project config already carried deploy, deploy_paths, and deploy_verify, plus prose notes saying "one rebuild at END of run" — it was still skipped, and the pass reported success.

Ask

Deployment becomes a mandatory, verifiable gate — in the pipeline and in the stories it works from:

implement-issues, Phase 6 hardening: when the profile defines deploy and any merged change matches deploy_paths, running deploy + deploy_verify is NOT optional and NOT skippable-by-silence. A pass that merged matching changes and did not deploy+verify must report itself as FAILED/incomplete (same severity as a red gate), never as success. The final report table gets an explicit deploy row: ran/verified, skipped-with-config-reason, or MISSED (error).
Story generation (prepare-work / plan-slices work-item contract): any story whose expected diff touches the target project's deploy_paths must carry an acceptance criterion of the form "deployed: run, <deploy_verify> green, live version == merged version". The requirements-checker then naturally audits it.
Loop mode: deploy runs once per pass (existing behavior), but a pass may not end between "merged" and "deployed" — deploy failure is a halt-policy stop condition (already documented) AND deploy omission becomes impossible by construction (e.g. the report template requires the deploy row).

Acceptance criteria

SKILL.md (implement-issues): Phase 6 rewritten as a gate with the failure semantics above; Phase 7 report includes the mandatory deploy row.
Work-item contract / prepare-work: deployment AC requirement documented for deploy_paths-matching stories.
A pass that merges a deploy_paths-matching change and skips deploy is impossible to report as success by following the skill text.

Deployment (required — part of this work item)

Changes to this plugin only reach agents via the versioned plugin cache. Definition of done includes: (1) bump the plugin version (plugin.json / marketplace metadata per repo convention); (2) refresh the installed cache on the workstation (claude plugin update <plugin>@samaschke-skills or the repo's documented update path); (3) verify the new version is the one listed in ~/.claude/plugins/cache/samaschke-skills/... and note the "restart sessions to apply" caveat. Do not close this issue at "merged".

## Context 2026-07-05, fritz-ai-local: an implement-issues pass merged changes matching the project's configured `deploy_paths` (`hooks/**`) and ended WITHOUT running the configured `deploy` command. The live Docker service kept running the old version (1.3.102 vs merged 1.3.105) until a human noticed the drift and ordered a manual rebuild. The project config already carried `deploy`, `deploy_paths`, and `deploy_verify`, plus prose notes saying "one rebuild at END of run" — it was still skipped, and the pass reported success. ## Ask Deployment becomes a mandatory, verifiable gate — in the pipeline and in the stories it works from: 1. **implement-issues, Phase 6 hardening**: when the profile defines `deploy` and any merged change matches `deploy_paths`, running deploy + `deploy_verify` is NOT optional and NOT skippable-by-silence. A pass that merged matching changes and did not deploy+verify must report itself as FAILED/incomplete (same severity as a red gate), never as success. The final report table gets an explicit deploy row: ran/verified, skipped-with-config-reason, or MISSED (error). 2. **Story generation (prepare-work / plan-slices work-item contract)**: any story whose expected diff touches the target project's `deploy_paths` must carry an acceptance criterion of the form "deployed: <deploy command> run, <deploy_verify> green, live version == merged version". The requirements-checker then naturally audits it. 3. **Loop mode**: deploy runs once per pass (existing behavior), but a pass may not end between "merged" and "deployed" — deploy failure is a halt-policy stop condition (already documented) AND deploy *omission* becomes impossible by construction (e.g. the report template requires the deploy row). ## Acceptance criteria - SKILL.md (implement-issues): Phase 6 rewritten as a gate with the failure semantics above; Phase 7 report includes the mandatory deploy row. - Work-item contract / prepare-work: deployment AC requirement documented for deploy_paths-matching stories. - A pass that merges a deploy_paths-matching change and skips deploy is impossible to report as success by following the skill text. ## Deployment (required — part of this work item) Changes to this plugin only reach agents via the versioned plugin cache. Definition of done includes: (1) bump the plugin version (plugin.json / marketplace metadata per repo convention); (2) refresh the installed cache on the workstation (`claude plugin update <plugin>@samaschke-skills` or the repo's documented update path); (3) verify the new version is the one listed in `~/.claude/plugins/cache/samaschke-skills/...` and note the "restart sessions to apply" caveat. Do not close this issue at "merged".

ksamaschke self-assigned this

2026-07-05 18:42:49 +00:00

ksamaschke referenced this issue from a commit

2026-07-05 18:54:28 +00:00

fix(implement-issues): require configured deploy gate (#2)

ksamaschke referenced this issue from a pull request that will close it,

2026-07-05 18:54:38 +00:00

fix(implement-issues): require configured deploy gate #3

ksamaschke closed this issue

2026-07-05 18:55:39 +00:00