Skip to content

Re-audit durable work-claim mechanics #5

Description

@chrhicks

Context

The 10 August 2026 architecture review identified repeated durable claim, stale-settlement, restart, atomic transition, and publication mechanics across Run execution, Acquire, and Process.

The Processing Project lifecycle refactor materially changed this evidence: Project claim and settlement now live inside the lifecycle module, while its worker only materializes deterministic evidence. The original proposal must therefore be re-audited before any shared abstraction is accepted.

Accepted outcome

Determine whether a small shared durable work-claim module still passes the deletion test across the current Run, Acquire, and Process implementations. Implement nothing unless the shared mechanics are truly identical and the interface remains smaller than the domain-specific policies.

Research scope

  • Re-inventory current claim-before-write, token ownership, stale settlement, restart, atomic domain transition, and publication behavior.
  • Separate shared mechanics from Run, Acquire, and Process evidence semantics.
  • Compare at least two radically different interface shapes.
  • Classify SQLite/filesystem/provider dependencies at each seam.
  • Identify which current tests would move to the shared interface and which must remain domain tests.
  • Apply the deletion test and reject a generic module if it only renames state or SQL.

Non-goals

  • A generic worker framework.
  • One acknowledgement type across physical, acquisition, and processing outcomes.
  • Moving domain policy into a shared persistence helper.
  • Real processing-library integration.
  • Implementation before the review demonstrates depth.

Acceptance criteria

  • The issue records current evidence rather than the pre-refactor architecture snapshot.
  • Shared and domain-specific invariants are listed separately.
  • Any proposed interface preserves distinct proof types and no-replay rules.
  • The deletion test and adapter test are explicit.
  • The result is either a bounded implementation task or a documented rejection with no code churn.

Proof boundary

This research can justify or reject a shared local SQLite/filesystem module. It cannot prove provider acknowledgement, hardware effects, physical capture, or processing quality.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions