Acquia Source × Bluefly: Work Tracking (Beads)¶

Updated: 2026-08-05 | Status: Active | Owner: Agent/Guild Owner

Overview¶

MVP work is tracked in Beads (durable work memory + issue tracking via bd CLI wrapped by blu beads).

Parent Bead: blueflyio-5ra — "MVP: source_connect_governance recipe for Acquia Source"

All child work items are linked as subtasks. Progress is visible via bd list and bd ready.

Bead Hierarchy¶

Phase 1: Discovery (1.1–1.4)¶

These are prerequisite research tasks. MVP does not start Phase 2 until all Phase 1 beads are closed.

canonical Bead.1 — 1.1 Confirm Acquia Source webhook structure and Cedar API
canonical Bead.2 — 1.2 Verify ContextControl Drupal integration API
canonical Bead.3 — 1.3 Verify Cedar policy decision storage format
canonical Bead.4 — 1.4 Map contributor dependencies and security status

Done when: Research findings documented in work comments; no blocker identified for Phase 2 start.

Phase 2: Baseline (2.1–2.4)¶

Assumes Phase 1 complete. These establish the working environment.

canonical Bead.5 — 2.1 Fresh Acquia Source site with Drupal CMS 2.1
canonical Bead.6 — 2.2 Install recipe_blucity
canonical Bead.7 — 2.3 Verify drupal/ai, drupal/cedar, drupal/eca installed
canonical Bead.8 — 2.4 Verify 1Password Key module integration

Done when: drush pm:list | grep -E "(ai|cedar|eca|key)" shows all 4 modules; 1Password token resolves without error.

Phase 3: Configuration (3.1–3.4)¶

Assumes Phase 2 complete. These are the main deliverables.

blueflyio-5ra.9  — 3.1 Author source_connect_governance Recipe
blueflyio-5ra.10 — 3.2 Create audit log entity definition
blueflyio-5ra.11 — 3.3 Create ECA model: webhook → Cedar check → log
blueflyio-5ra.12 — 3.4 Wire Acquia webhook → Drupal receiver

Done when: Config YAML committed to Git; ECA model importable; webhook test payload received in Drupal queue.

Phase 4: Demonstration (4.1–4.4)¶

Assumes Phase 3 complete. These are proof-of-work and verification.

canonical Bead.13 — 4.1 Live demo: Canvas publish → audit receipt
canonical Bead.14 — 4.2 Verify recipe repeatable on Site B

Done when: Demo video recorded (5 min); Site B has identical governance policies; Governance Officer signs off.

CLI Usage¶

List all MVP work¶

bd list

Shows tree structure. Status icons: - ○ = open - ◐ = in_progress - ● = blocked - ✓ = closed - ❄ = deferred

See ready/unblocked beads¶

bd ready

Shows all beads with no active blockers, sorted by priority.

Claim a bead (start work)¶

bd claim canonical Bead.9

Changes status to ◐ in_progress. Associates with your account.

Update bead status¶

bd update canonical Bead.9 --status closed

Marks complete. Add evidence in bead comments before closing.

Show bead detail¶

bd show canonical Bead.9

Shows full history + all comments + linked parent/children.

Add comment/evidence¶

bd update canonical Bead.9 --comment "AT-1 passed: recipe applies without errors"

Keep evidence in bead, not scattered in Slack/email.

Work Standards¶

Commit message format¶

Every commit references the active bead:

feat: 3.1 Author source_connect_governance recipe

Recipe adds:
- Cedar policy config for healthcare compliance
- ECA model for webhook → check → log
- Audit log entity schema

Bead: canonical Bead.9

Required: Bead ID in message. CI pre-commit gate enforces this.

Evidence in bead comments¶

When completing a bead, add evidence before marking closed:

ACCEPTANCE TEST: AT-3 PASS
Command: drush eca:run source_connect_governance
Result: Cedar policy executed; audit log created with:
  - timestamp: 2026-08-05T14:23:45Z
  - policy_id: healthcare-v2
  - decision: PASS
  - component: Patient FAQ

Evidence artifact: screenshot of Drupal audit log entity

Phase blockers¶

If Phase 1 discovers a blocker (e.g., "ContextControl module doesn't exist"), mark dependent Phase 2/3 beads as ● blocked:

bd update canonical Bead.5 --status blocked --priority 1 --comment "Blocked: ContextControl module unavailable. Phase 1.2 investigation needed."

This stops execution and escalates to Guild Owner for decision.

Status Labels (Auto-Added)¶

Label	Meaning	Action
`in-progress`	Someone claimed and is actively working	Nothing (auto-set on claim)
`blocked`	Upstream blocker (phase dependency, missing package, etc.)	Escalate to Guild Owner
`closed`	Complete with evidence	N/A
`deferred`	Deprioritized but not rejected	Revisit in P1+

Daily Workflow (Example)¶

Monday morning:

bd ready
# Output: 5 open Phase 1 beads ready to start
bd claim canonical Bead.1
# Now in_progress

Work on discovery (1.1): confirm webhook structure - Read Acquia docs - Inspect webhook payload - Document findings in bead comments

End of day:

bd update canonical Bead.1 --comment "Webhook payload schema confirmed. Example: {...json...}. No blockers for Phase 2."
bd update canonical Bead.1 --status closed
# Now showing as ✓ closed

Tuesday:

bd ready
# Output: 4 open Phase 1 beads + 4 Phase 2 beads (now unblocked)
bd claim canonical Bead.2
# Start next discovery task

Escalation Path¶

Blocker found → Update bead, mark ● blocked → Guild Owner reviews → Decision: - Proceed as-is: Update bead, remove blocker label, continue - Workaround: Add comment with workaround, mark progress - Defer: Mark ❄ deferred, link to P1 bead

Scope creep → Recognize it's out of MVP → Create P1 child bead (e.g., canonical Bead.P1.1) → Keep MVP focused

Question about contrib → Add comment in bead → Guild Owner responds → Continue or escalate

Metrics (Dashboard View)¶

# Total beads
bd list | grep "Total:"
# Output: Total: 14 issues (14 open, 0 in progress)

# Progress (as work completes)
bd list | grep "Total:"
# Output: Total: 14 issues (8 open, 3 in progress, 3 closed)

# Ready to start (unblocked)
bd ready | wc -l
# Shows count of actionable beads

Notes for Guild Owner (Owner)¶

Beads are the source of truth for MVP progress
Comments in beads become evidence for acceptance tests
Block/unblock beads to enforce phase ordering
Don't create ad-hoc work outside beads (everything goes in bd)
Weekly: check bd list to see if any are blocked; unblock or escalate

Next: Run bd ready to see what's ready to start.