Skip to main content

0001 — CRM Deals Custom Fields (BOT-4662) duplicate Story family remediation

Delivery / Program Management — decision record (ADR-style).

Provenance: the remediation was executed 2026-07-16; this record was written 2026-07-27 to give it a durable home, extracted verbatim from the Sprint 1 plan's ## Deviations section (no reconciliation pass file recorded it). Everything below the Decision heading is what was recorded at the time. Items marked unrecorded were never captured and are not reconstructed here.

Context​

While filing the QA task BOT-4688 on 2026-07-16, jira-alignment-check found that Epic BOT-4662 (CRM Deals Custom Fields, child of the umbrella BOT-4597) carried two Story sets covering the same scope — the four PRD user stories QACF-S01–S04 plus the scope-guard story QACF-S01-NEG, all in crm-actions-custom-fields.md. The canonical set titles each Story with its PRD user-story title verbatim; the duplicate set uses AC-narrative titles citing composite QACF-S0x/{AC,NEG}-n ids in the description. The pairing is not positional — the two sets order S03/S04/NEG differently, so match on the covered story, never on key order:

CanonicalDuplicateCovers
BOT-4663BOT-4675QACF-S01
BOT-4664BOT-4676QACF-S02
BOT-4665BOT-4678QACF-S03
BOT-4666BOT-4679QACF-S04
BOT-4667BOT-4677QACF-S01-NEG (scope guard rails, NEG-1–NEG-4)

Five keys per set against four numbered user stories, because QACF-S01-NEG is a story in the PRD's Section-8 tables but not an S0n — verified against the board 2026-07-27.

At discovery the Epic was wired across both sets: the 4 FE Tasks (BOT-4680–4683) were split-linked only to the duplicate set, while the BE Tasks (BOT-4668–4673) and BOT-4688 already pointed at canonical.

Decision​

Keep the canonical per-user-story set; retire the duplicates in place. Decided and executed by Hilmi Muktitama (TPM) on 2026-07-16, in three operations:

  1. A Duplicate link between each pair — canonical is duplicated by duplicate, verified in both render directions on the board rather than from JSON field names.
  2. The 4 FE Tasks (BOT-4680–4683) were additionally split-linked to their canonical counterparts (BOT-4663 / 4664 / 4667), bringing them level with the BE Tasks.
  3. Each duplicate Story (BOT-4675–4679) received an explanatory comment and was transitioned to Won't Fix.

Unrecorded: whether any alternative was weighed. Do not infer a rationale from the operations above.

Cause (reconstructed 2026-07-27 from Jira creation metadata)​

Both sets were batch-created by an agent session, 17.5 hours apart under two different accounts: canonical by Agus Suparman (5 Stories in 23s, 2026-07-15 17:40), duplicates by Baghiz Firdausa (5 Stories in 14s, 2026-07-16 11:12). Neither was hand-filed.

The duplicate bodies are FE task-breakdown output filed at Story level rather than PRD user stories — each carries an FE-readiness verdict as its content (BOT-4675 ✅ Actionable (FE — Tasks 1.1, 1.2, 2.1), BOT-4678 🚫 Skipped — BE-only; no FE code, BOT-4679 No FE code — ACs met trivially). BOT-4678 is the clearest signal: a Story whose own description states it contains no work. A second session ran an FE breakdown over the same PRD and emitted Stories where the alignment contract expects Tasks parented to the existing Stories.

The granularity was therefore not the per-AC shape; both sets are one-Story-per-user-story. The defect is hierarchy level, and the missing pre-flight check is "does this Epic already carry a Story set for these user stories?"

Consequences​

  • BOT-4662 has one authoritative Story set. Sprint planning, sprint-jira-sync, and jira-alignment-check resolve against BOT-4663–4667.
  • Trade-off accepted permanently: the FE Tasks' original split from links to the now-closed duplicate Stories cannot be removed — the Atlassian MCP server exposes no delete-link tool. Those four Tasks show a stale split from to a Won't-Fix Story alongside the correct canonical link indefinitely. Harmless but visible; recorded here so future alignment passes recognise it as a known residual and do not re-remediate it.
  • Agent sessions filing against a shared board need a pre-flight existence check. Two sessions broke down the same PRD a day apart and neither saw the other's Stories. Before creating Stories on an Epic, confirm the Epic carries no Story set for those user stories already; a breakdown pass that finds one contributes Tasks parented to those Stories instead of a parallel set.
  • BOT-4662 remains manually planned at one-Story-per-user-story, so the automated jira-sync / main-full pipeline — which creates one Story per composite AC id — must never be pointed at it.