ADR-0047: Remove journal from work item field surface for loop-centric execution state

Status: accepted | Date: 2026-05-31

References: ADR-0043, ADR-0026, RFC-0006, RFC-0000:C-WORK-DEF

Context

ADR-0026 added a journal field to work items for execution tracking. ADR-0043 proposed removing it entirely and redirecting execution tracking to a work-item-centric .govctl/loops/<WI-ID>/ layout. RFC-0006 then introduced a loop-centric model where .govctl/loops/<loop-id>/state.toml is the state anchor for loop execution.

Three problems with ADR-0043’s “remove and redirect” approach:

Breaking change: Some work items may contain legacy inline execution-history entries. Removing the field entirely would force immediate migration.
ADR-0043 is superseded by RFC-0006: Its target path (.govctl/loops/<WI-ID>/) conflicts with the loop-centric model (.govctl/loops/<loop-id>/).
RFC-0000:C-WORK-DEF mandates journal: Removing it contradicted the normative clause without a proper amendment path at the time this decision was made.

The loop execution model (RFC-0006) makes inline execution-history data obsolete: loop execution state in .govctl/loops/<loop-id>/state.toml is the source of truth for active execution tracking. Any work item’s inline data is legacy compatibility data.

Rather than preserve journal as a separate read-only field, we remove it from the path-addressable work item field surface. Existing inline data may still be parsed so work show and render output can display historical entries without forcing an immediate migration.

Decision

Remove journal from the path-addressable work item field surface. journal MUST NOT be accepted by work get, work add, work edit, work remove, or work tick as a separate field.

For backward compatibility, implementations MAY continue to deserialize legacy inline content.journal entries and render them from work show / work item render output. This compatibility path MUST NOT make journal available as a normal editable or fetchable field.

Loop execution state is stored through the loop-centric state model in RFC-0006 and ADR-0046, not through a work item field.

Consequences

Positive:

Existing work items with legacy inline data continue to render correctly
Clear model boundary: journal is not a Work Item field even though legacy data can render
Historical execution data remains inspectable through work item show/render output when present
Establishes loop-centric state as the future path for active execution tracking
Supersedes the conflicting ADR-0043 with a more practical approach

Negative:

Legacy inline data may persist in external work item files, adding minor file size overhead
Compatibility parsing remains until the project intentionally removes legacy render support
No automated migration path for durable insights from legacy inline data to notes (manual process)

Neutral:

govctl check gains an informational diagnostic for work items with legacy inline data
JournalEntry struct and render code remain in the codebase for legacy render compatibility
New work items omit content.journal

Alternatives Considered

Remove journal from field surface while preserving render compatibility (accepted)

Pros: Clear field model: journal cannot be fetched or edited separately, Historical entries remain visible through show/render, No breaking changes for work items with legacy inline data
Cons: Legacy journal data persists indefinitely, Render compatibility keeps journal parsing code

Remove journal field entirely and force migration (rejected)

Pros: Clean break with no legacy compatibility path
Cons: Requires forced migration; destroys readable history, Breaking change for work items with legacy inline data
Rejected because: Immediate forced migration is unnecessary; ADR-0043 target path also conflicts with RFC-0006 loop-centric model

Keyboard shortcuts