Jordan-Hall / Jordan-Hall/browser

[P2][CODE-03] Action journal, undo and compensation UI

Open
#74 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Programme: #1
Epic: #24

## Objective
Give users one coherent history and recovery model across local edits and external actions while accurately distinguishing true undo from compensating operations and irreversible effects.

## Scope
- Unified action journal referencing operation IDs, artifacts, source state, approvals and receipts.
- Local reversible actions: file/layout/version restoration.
- External compensatable actions: cancellation, deletion, refund/reversal requests as new transactions.
- Irreversible/uncertain action states with explicit next steps.
- User-facing diff/history timeline and “what can be undone?” metadata.
- Compensation authorization/verification through TX-01/TX-02.
- Preserve immutable receipts/audit where required while reverting local presentation/state.

## Product rules
- Compensation is not rollback and may fail or require new approval.
- Old approvals cannot be reused for materially different compensation actions.
- UI must never imply that stopping a task reversed an accepted external action.

## Acceptance criteria
- [ ] Every supported action declares reversible / compensatable / irreversible-or-uncertain behavior.
- [ ] Local file/layout restore reproduces a prior valid version.
- [ ] External compensation creates a new proposal/approval/receipt flow.
- [ ] Stale approval cannot authorize compensation automatically.
- [ ] Uncertain states remain visibly unresolved until verified/reconciled.
- [ ] Journal remains coherent across crash/restart and source refresh.

## Dependencies
- CORE-02
- TX-01

**First phase:** P2
**Maturity target:** P4
**Owner:** harness-pc-providers

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the CORE-02 and TX-01 dependencies, then map the action journal, approval, receipt, and recovery entry points in the repository. Done means the listed acceptance criteria hold across local restoration, external compensation, stale approvals, uncertain states, crash/restart, and source refresh.

Written by the indexing model from the issue text.

Assessment

Domain
backend, frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.