ai-delivery-workflow 0.4.0 → 0.5.1

package/skills/ai-delivery-manage-git/SKILL.md

@@ -27,7 +27,7 @@ Write every Git decision, transition record, scope declaration, and workflow doc
 - `line/<product-id>`: latest verified cumulative development lineage, which may remain ahead of production;
 - `version/<version-id>-<slug>`: one planned cumulative version;
 - `work/<version-id>/<task-id>-<slug>`: one dynamic technical work package;
-- `release/<release-id>-<slug>`: one explicit user-requested release candidate;
+- `release/<release-id>-<slug>`: one explicit user-requested release candidate, created from the frozen `main` snapshot and, for incremental release, integrated with exactly one target `version-ready` Tag;
 - `release-fix/<release-id>/<defect-id>`: one isolated release-candidate correction;
 - `hotfix/<hotfix-id>-<slug>`: urgent correction from the current production Tag.
 
@@ -45,13 +45,15 @@ Reject environment branches (`dev`, `sit`, `staging`, `production`), `rollback-*
 ## Release Operations
 
 1. At planned-version closeout, create immutable code `version-ready/<version-id>/rN`, fast-forward code `line/<product-id>`, commit workflow materials, then create workflow `workflow-ready/<version-id>/rN`; stop without changing code `main`.
-2. Serialize production release transitions only after explicit user release intent.
-3. Create `release/<release-id>-<slug>` from the selected target's exact version-ready Tag. Never merge each intermediate Tag or build from a movable line/version branch head.
-4. Apply any release-only correction on `release-fix/*`, create a new release candidate, and repeat impacted verification.
-5. Freeze and Tag the exact tested release commit before production deployment. Never move or reuse a release Tag.
+2. Serialize production release transitions only after explicit user release intent. At R00, record the exact `main` commit as the production-base snapshot and hold that snapshot for the whole candidate.
+3. Create `release/<release-id>-<slug>` at the recorded `main` snapshot. At R04, for incremental release merge exactly one selected target `version-ready` Tag with `--no-ff`; the resulting merge commit is the release candidate. For same-version redeploy, require the target Tag to be already reachable from the snapshot and use the snapshot itself as the candidate without a new merge. Never merge intermediate Tags or build from a movable line/version branch head.
+4. During candidate assembly, verification, approval, and deployment, any change to `main` makes the candidate stale. Stop, preserve its evidence, and recreate the release branch and candidate from a new `main` snapshot.
+5. Apply any release-only correction on `release-fix/*` from the active candidate, merge it into a new candidate, and repeat impacted verification. Freeze and Tag the exact tested candidate before production deployment; never move or reuse a release Tag.
 6. Promote the same artifact digest through environments; Git branches do not select environment state.
-7. After successful production verification, fast-forward `main` to the exact deployed commit. Same-version redeploy may leave `main` unchanged.
-8. After failed deployment and image rollback, keep `main` unchanged and preserve failed release and version Tags.
+7. After successful production verification, fast-forward `main` to the exact deployed release candidate commit. Before R10 archive, synchronise every deployed `release-fix` commit into `line/<product-id>` through the protected Git operation and record a sync receipt; if the commit is already reachable from line, record an explicit no-op receipt. Candidates that omit a production-successful fix are stale.
+8. Same-version redeploy may leave `main` unchanged when it already names the deployed commit. After failed deployment or image rollback, keep `main` and `line` unchanged, preserve failed release/version Tags, and do not create a rollback branch.
+
+Use the package-delivered `scripts/release-git.mjs` interface for these protected transitions. `create-candidate` requires `--release-id`, `--release-branch`, `--expected-main`, one `--source-tag`, its `--source-commit`, `--receipt`, and `--apply`. `promote` additionally requires `--production-verification <R09-production-verification/production-verification.json>`; the JSON must bind the release ID, `decision: released`, R00 main commit, verified candidate commit, and deployed commit. `sync-release-fix` requires that same `--production-verification`, a schema-2 product-line `--candidate-inventory <predecessor-R10 JSON>`, and, with `--apply`, a distinct unused `--successor-candidate-inventory <new-R10 JSON>`. The inventory binds `product_id`, `line_branch`, the active candidate, and every candidate's own `release_id`, commit, and status. The script, not a caller-supplied stale list, derives product-line-wide `stale_candidate_ids` and `candidate_status_updates` for selectable candidates that omit the successful fix, then writes the immutable successor inventory and binds both inventory paths and checksums in its receipt. Every action returns a structured JSON receipt; omitting `--apply` produces a zero-write plan, and an already-reconciled fix returns an explicit idempotent receipt rather than silently succeeding.
 
 ## Hotfix Operations
 

package/skills/ai-delivery-manage-git/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Manage Delivery Git"
-  short_description: "Manage iteration branches, worktrees, tags, and release locks"
+interface:
+  display_name: "Manage Delivery Git"
+  short_description: "Manage iteration branches, worktrees, tags, and release locks"
   default_prompt: "Use $ai-delivery-manage-git to perform the required transition in the correct workflow or code repository."

package/skills/ai-delivery-manage-git/references/git-policy.md

@@ -23,15 +23,19 @@ Use stable delivery IDs, not human names or dynamic AI roles.
 
 ## Cumulative Version Policy
 
-Create every next planned version from the current product line head. Close a verified version by creating immutable `version-ready/<version-id>/rN` and fast-forwarding `line/<product-id>` to it. Historical version tags and manifests never change. A correction after closeout normally becomes the next planned version.
+`product-id` is the stable product-line identity established when the project is bootstrapped. Create `line/<product-id>` once, from the current `main`, when the product begins its first planned version. Create every later planned version from the current line head. Close a verified version by creating immutable `version-ready/<version-id>/rN` and fast-forwarding `line/<product-id>` to it. Historical version tags and manifests never change. A correction after closeout normally becomes the next planned version.
 
 `main` represents current successful production, while `line/<product-id>` represents the latest verified cumulative development. The line may advance through any number of release-ready versions without changing production.
 
 ## Release Policy
 
-Create a release branch only after explicit user release intent. Build it from the exact target version-ready Tag. Verify every adjacent code and workflow commit edge from current production through the target; a direct production-to-target check does not prove the middle versions. Use intermediate versions for lineage and material closure, not repeated code merges.
+Create a release branch only after explicit user release intent. At R00, capture the exact current `main` head as the immutable `expected_main` base. Verify every adjacent code and workflow commit edge from current production through the target; a direct production-to-target check does not prove the middle versions. The captured main commit must still be the production head. In an incremental release it must be an ancestor of the exact target immutable version-ready Tag; in a same-version redeploy the target Tag must already be an ancestor of or equal to the captured main commit.
 
-After successful production verification, fast-forward `main` to the deployed release commit. For same-version redeploy, record a new release ID and Tag while allowing `main` to remain unchanged.
+At R04, create `release/<release-id>-<slug>` from `expected_main`. For incremental release, merge exactly one target Tag with `--no-ff` and bind all later verification, approval, deployment, and release Tags to that result merge commit. For same-version redeploy, when the target Tag is already contained by `expected_main`, bind them to the snapshot itself and record no new merge. Use intermediate versions for lineage and material closure, not repeated code merges. A main change during candidate work makes the candidate stale; preserve it and start a new R00 request rather than changing its base.
+
+After successful production verification, fast-forward `main` only from the recorded `expected_main` to the exact deployed candidate commit. `promote` must receive the immutable R09 `production-verification.json` decision, whose `schema_version` is `1`, `operation` is `production-verification-decision`, `release_id` is exact, `decision` is `released`, and `expected_main_commit`, `verified_release_commit`, and `deployed_commit` are full immutable object IDs. The promotion receipt retains the evidence path and SHA-256. For same-version redeploy, record a new release ID and Tag while allowing `main` to remain unchanged only when it already equals the exact candidate. A failed or rolled-back release does not advance `main`.
+
+Create a release-fix only from the active candidate. When its deployed candidate has passed production verification, synchronize the exact fix commit into `line/<product-id>` before R10 archive through the protected operation. Supply the released R09 decision and a schema-2 immutable candidate inventory scoped to that product line: `scope: product-line`, `product_id`, `line_branch`, active candidate ID/commit, and a unique `candidates` list whose records each retain `candidate_id`, `release_id`, `candidate_commit`, and `status`. The root has no `release_id`; the active and verified candidate records must belong to the operation's release ID. The operation derives, rather than accepts, stale candidates across the product-line inventory: it emits `candidate_status_updates` with `status: stale` for selectable candidates that do not contain the fix, while already `stale` or `released` candidates are not rewritten. With `--apply`, provide a distinct `--successor-candidate-inventory` path. The operation writes that successor without changing its predecessor, records its path/checksum in the receipt, and updates the successor's statuses and active candidate pointer. A later fix starts from the latest immutable successor. Record the release ID, source ref/commit, verified release commit, old/new line heads, merge strategy, evidence hashes, predecessor/successor inventories, derived stale candidate IDs/status updates, and result. If the line already contains the fix, record an explicit idempotent no-op receipt and require the exact same successor inventory.
 
 ## Environment And Rollback Policy