Skip to content

f6a8c421.md

Latest commit

 

History

History
194 lines (140 loc) · 10.4 KB

f6a8c421.md

File metadata and controls

194 lines (140 loc) · 10.4 KB
Raw
uid f6a8c421
type decision
state active
title ADR-036 — Pipeline Bucket Taxonomy: Inbox / Accepted / Active / Archive
description Replaces the ambiguity-laden `3-next` bucket with `2-accepted` and reorders for monotonic forward flow. Applies to 2-design, 3-specify, and 4-build pipeline stages. UIDs stable across the rename; migration is title/slug-level only.
owner argus
created 2026-04-20
modified 2026-06-18
created_by argus-a29
decision_number ADR-036
proposer Mike Maziarz
status done
accepted_on 2026-04-20
endorsed_by mike-maziarz
member_of
tags
adr-036
governance
pipeline
buckets
naming
grooming
p1
file_ext md
schema_version 2
extraction_scope ship
relationships
type uid
references
020274e0
type uid
references
fe189cd4
type uid
references
32c75ba0
type uid
references
a93faa83
subsystem_hub
8dd772a0
capsule_version 2.5

ADR-036 — Pipeline Bucket Taxonomy: Inbox / Accepted / Active / Archive

📍 Vault Path: tropo-subsystems → Tropo Governance → ADR-036 — Pipeline Bucket Taxonomy: Inbox / Accepted / Ac...

🔗 This file — UID f6a8c421 · type decision · state active · status done

📥 Cited by (1):

Status

ACCEPTED 2026-04-20 by Mike Maziarz. Proposed and adopted in the same session — Mike's direct observation that 3-next had drifted into ambiguity across multiple roles (backlog / priority queue / "maybe later" pile). Rename executed via mechanical sub-agent sa.research record 031.

Context

Each pipeline stage in work-pipeline (020274e0) that carries groomable work uses a four-bucket sub-structure. The original taxonomy was:

  • 1-inbox — unsorted, unreviewed intake
  • 2-active — currently being worked
  • 3-next — acknowledged, deferred
  • 9-archive — done, abandoned, superseded

This worked but 3-next developed semantic drift in practice. Across sa.research 023's real-state inventory (2026-04-20) and multiple sessions of grooming, 3-next was being used three different ways:

  1. Backlog — "we'll get to this eventually"
  2. Priority queue — "this is next up after current active work"
  3. Maybe later — "interesting, not yet a commitment"

Three semantics in one container is a lookup-surface defect (same class as sa.research 023 board-def finding — a capsule meaning three things at once is a capsule meaning nothing). A reader scanning 3-next can't tell which of the three modes applies to any given entry.

Meanwhile the flow read awkwardly: inbox → active → (maybe back to) next → active. The "back to next" transition is sideways; it encodes retreat. Every Kanban-aware reader expects forward flow: Backlog → Ready → In Progress → Done.

Decision

Adopt a four-bucket taxonomy with monotonic forward flow:

1-inbox → 2-accepted → 3-active → 9-archive
Bucket Semantic contract
1-inbox Unreviewed intake. No owner commitment. Anyone can drop; stage owner groomss.
2-accepted Owner has explicitly accepted the work as real. Not yet scheduled. Reviewable. Auditable — "when did Metis accept the Innovation Pipeline Redesign?" has a concrete date answer.
3-active Currently being worked.
9-archive Terminal state. Done, abandoned, superseded, or cancelled.

Scope: applies to three pipeline stages that carry groomable work — 2-design (fe189cd4), 3-specify (32c75ba0), 4-build (a93faa83). Does NOT apply to 1-ideate (ee3bedb4) or 5-deploy (08f29ff6) — those stages do not carry the four-bucket structure by design.

9-archive numbering preserved. Kept at 9 (not renumbered to 4) for two reasons: (a) the gap signals "terminal state, separate from the active flow" visually in sorted listings; (b) leaves room for future intermediate buckets if the model ever needs one (e.g., a 5-blocked parallel lane), without renumbering archive again.

Why accepted, not next / ready / queued / approved?

Mike's proposal specifically named accepted. Alternatives considered during Argus A29 review:

Candidate Why rejected
next (status quo) Three-ways-ambiguous in practice — the problem we're solving.
ready Kanban-canonical but passive-voice. Doesn't signal WHO approved it.
queued Generic backlog feel. No commitment semantic.
approved Close to accepted but slightly more governance-bureaucratic.
accepted Precise — owner has read and committed. Matches governance vocabulary ("ADRs are accepted," not "queued"). Slight awkwardness as past-participle-next-to-nouns is a fair price for semantic precision.

accepted wins because it encodes the explicit owner handshake that the other three candidates leave implicit.

Consequences

What becomes easier

  • Auditable commitment. "When did owner X accept work Y?" has a concrete answer (the timestamp the artifact's member_of: moved into 2-accepted).
  • Review discipline. Two distinct decisions — "is this real work?" (inbox → accepted) and "work on this now?" (accepted → active) — instead of one conflated move.
  • Linear flow. Every transition moves forward; no sideways moves. Matches Kanban intuition every user already has.
  • Grooming clarity. Inbox = not yet decided. Accepted = yes, will do. Active = doing. Archive = done. Each bucket has one meaning.

What becomes more constrained

  • Tighter grooming regime. Owners must now take a visible "accept" action before scheduling. Things that used to sit ambiguously in 3-next now either get explicitly accepted (committed) or stay in inbox (ambiguous). No more passive-backlog holding pattern.
  • Deferred-from-active work flows backward visually — 3-active → 2-accepted (paused but still committed). That's correct semantics but requires buying into "moving back a bucket means pausing, not retreating."

What DOES NOT change

  • Graph structure: member_of: edges are unaffected. Work objects living in the old buckets continue to live in the renamed buckets — only the container title changed.
  • UIDs: stable across the rename. No cross-reference breakage.
  • Board-rendering: project-board kernel seed (c72f1a85) queries tag=pipeline-bucket first, not specific bucket names. Renders continue to work.
  • Other pipeline stages: 1-ideate and 5-deploy are unchanged (they don't use the four-bucket pattern).
  • Pipeline root prose: no parent project bodies reference the old bucket names in prose (verified before migration). No prose sweep needed.

Migration

Executed mechanically by sa.research 031 on 2026-04-20:

Renamed in place (UID-stable — label-only change, all member_of: pointers from children keep resolving):

  • 63b69c61: 3-specify/2-active → 3-specify/3-active
  • 04ddb018: 3-specify/3-next → 3-specify/2-accepted
  • a5f7a762: 4-build/2-active → 4-build/3-active
  • 2d59f2de: 4-build/3-next → 4-build/2-accepted

Pre-existing and unchanged:

2-design bucket completion: 2-design currently has only 1-inbox plus 6 loose design artifacts. Full-pattern buckets for 2-design will be created just-in-time when grooming demand appears. Not part of this ADR's migration.

Total: 4 renames = 4 file operations. Graph integrity preserved.

Open Questions (deferred)

  1. Should 1-ideate carry a bucket structure too? Currently 1-ideate (ee3bedb4) does not. Arguments for: consistency. Arguments against: ideate is more free-form / exploratory; imposing the four-bucket structure there may add ceremony without value. Recommendation: leave as-is for v1.3; revisit if concrete usage patterns show need.

  2. Should 5-deploy carry a bucket structure? Similar reasoning. Deploy is terminal; intake/accepted/active don't map cleanly. Recommendation: leave as-is.

  3. Does 2-accepted stack with a freshness / refresh-cadence rule? Per ADR-035 Surface 5 (a7c4e5b2) on living references, should accepted items get a valid_until: stamp that forces a re-accept if they sit too long without advancement? Recommendation: not in this ADR; consider as a follow-up grooming directive.

Cross-References

Provenance

Proposed by Mike Maziarz on 2026-04-20 during the A29 session, after observing 3-next ambiguity across grooming passes. Argus A29 reviewed proposed design, named alternatives, recommended adoption. Mike accepted same session. Rename executed mechanically via sub-agent; no prose updates required in parent stages (verified clean before dispatch).

This is the second ADR filed during A29's session (the first was ADR-035 Declared-Presence (a7c4e5b2)). Both follow the pattern: name the defect class, choose precise vocabulary, leave UIDs stable during migration.

ADR-036 | Pipeline Bucket Taxonomy | Proposed by Mike, accepted same session | Argus A29 + Mike Maziarz | 2026-04-20 "Inbox is intake. Accepted is commitment. Active is motion. Archive is terminal. Four states; clean contracts."