CLI

[Apartman36]

How can Bernstein preserve audit-grade lineage when multiple CLI coding agents modify the same artefact across parallel worktrees?

[chernistry]

Thanks for the question. Honest answer: Bernstein doesn't fully solve this yet. Right now we lean on per-worktree branch names plus signed commits with agent identity in the trailer, then reconcile in CI with a lineage check that fails the merge if any artefact has parallel edits without a recorded ancestor. It's brittle. The plan for the next milestone is a content-addressed lineage log per artefact (append-only, agent-scoped), so concurrent edits show up as siblings instead of silently winning a race. If you've got a specific artefact type in mind I can point at the code path.

[chernistry]

Note: The comment this reply originally addressed (by @Miensoap, 2026-05-14) was deleted by the author. Preserving the gist for thread continuity — it was a detailed write-up of a "timeline v3" architecture: a two-layer run-history model (assistant message metadata + a separate background_task projection), with schemaVersion=3 ordered timeline[] as the source of truth, persistence triggered on text.done rather than per-event, detached sub-agent bodies held in a BackgroundTaskTracker accumulator that commits on terminal lifecycle, and the parent timeline only storing lightweight background_task_ref placeholders.

Thanks @Miensoap for the detailed write-up. Two parts of the design stood out:

1. Two-layer storage (assistant metadata + background_task projection): parent timeline holds only a background_task_ref placeholder while detached child bodies live in a separate projection. Clean separation for matching stream-reconnect and replay grain.

2. text.done-triggered commit + accumulator pattern: not writing per event, but committing the timeline together with the finalised assistant text. The dedup/ordering guards (processedEventIds, textDonePersisted) are tidy.

Honest read on scope, though: this thread's original question was about a different problem — parallel-edit lineage on the same artefact (multiple agents editing one file concurrently; who wrote what when, who the ancestor is, cryptographically provable). timeline v3 is focused on run-history persistence and replay, which is a different layer.

Bernstein shipped lineage v1 on 2026-05-13 in v1.11.0: Sigstore-style per-artefact signed log + EU AI Act Article 12 evidence pack + standalone bernstein-verify CLI. Design: ADR-009.

We won't pivot direction, but the two-layer storage + ref-placeholder pattern is worth borrowing when we connect lineage entries to in-run timelines in v2.

[chernistry]

@Miensoap — captured the pattern as a v2 backlog item: #1249.

The core idea is to introduce a parent ref + detached child chain split into the lineage entry schema. ADR-010 will formalise the design, but if you'd like to take a shot at implementing it yourself, the issue is open to claim and PR. ADR-009 is the v1 reference point for entry schema and verify flow.