T-H98A-last-reviewed-rebase-collision

Status: closed/superseded · Impact: low · Complexity: small

Auto-generated from a /sdlc:task-work post-mortem. Review and promote to open/ready before picking up.

Goal

/sdlc:task-work Step 5a (ensure-ready, on the feat branch) and Step 5b (start-commit, on main) each write a different last_reviewed value into the same task file. On Step 5b.6’s git rebase main, the two values collide and surface as a merge conflict the operator has to resolve by hand. Closing this gap means the gate-then-flip sequence is fully automatic with no rebase prompts. Surfaced during T-E4ZB-clarify-out-of-scope-requirement.

Today

Concrete sequence observed during the originating task’s run:

1. Step 5a (/sdlc:task-ensure-ready) stamped readiness_verified_at: 2026-05-21T05:00:39Z on the feat branch, leaving last_reviewed: 2026-05-20 (unchanged from the task’s prior triage).

2. Step 5b.1 edited the task file on main and set last_reviewed: 2026-05-21 (today, per the skill spec) plus status: in-progress and the new readiness_verified_at:.

3. Step 5b.6’s git rebase main from the feat branch surfaced:

   CONFLICT (content): Merge conflict in
     docs/planning/tasks/2026-05-19-clarify-out-of-scope-requirement.md

   The conflict was solely on the last_reviewed line — main had '2026-05-21', feat had '2026-05-20'.

The conflict is mechanical (main always wins because the value is monotonic — it’s a UTC date stamped at Step 5b time, never earlier than Step 5a’s date), but task-work’s spec does not call this out, and git rebase does not know the field is monotonic.

Proposed

The 5a → 5b → rebase sequence completes without a merge conflict on last_reviewed. Either Step 5a also bumps last_reviewed to today (matching what Step 5b will write), OR Step 5b explicitly resolves the conflict in favor of main and the skill spec documents the auto-resolution.

Approach

1. Decide: bump-in-5a, or auto-resolve-in-5b. Bump-in-5a is simpler (the two commits write the same value, no conflict surfaces) but slightly stretches ensure-ready’s scope (it currently only touches readiness_verified_at and definition_gap). Auto-resolve-in-5b keeps ensure-ready tight but adds rebase complexity.
2. If bump-in-5a: edit plugin/skills/task-ensure-ready/SKILL.md Step 4 to also set last_reviewed to today’s date when stamping readiness_verified_at. Update the SKILL’s input contract / “Notes” wording. Update task-work Step 5b.1 prose to note the value will already match.
3. If auto-resolve-in-5b: edit task-work Step 5b.6 to use git rebase -X theirs main (or post-rebase scripting that detects the last_reviewed collision and keeps main’s value). Either way, document the auto-resolve so a future contributor doesn’t break it by accident.
4. Verify by running /sdlc:task-work end-to-end on a fresh task and confirming Step 5b.6 returns success without a conflict.

Files to touch

Location	Kind	Change
plugin/skills/task-ensure-ready/SKILL.md	modify	Step 4 may need a
plugin/skills/task-work/SKILL.md	modify	Step 5a / 5b prose updates,

Acceptance criteria

• AC-1: A clean end-to-end run of /sdlc:task-work <slug> against a task with a last_reviewed value older than today completes Step 5b.6 (git rebase main) without surfacing any merge conflict.
• AC-2: plugin/skills/task-work/SKILL.md documents which side of the gate is authoritative for last_reviewed, so a future contributor reading the spec can tell whether the field gets bumped in 5a, 5b, or both.

Out of scope

• General improvements to ensure-ready’s frontmatter writes beyond last_reviewed.
• Other rebase-conflict shapes the gate-then-flip flow could produce (none observed in this run; address as new gaps surface).

Dependencies

• none

Discovery context

Spawned by /sdlc:task-work post-mortem of T-E4ZB-clarify-out-of-scope-requirement on 2026-05-21.

---

← Back to Tasks