Jordan-Hall / Jordan-Hall/browser
[P1][TX-01] Action proposals, approvals and commit journal
- Dominant language
- No language data
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Programme: #1
Epic: #26
## Objective
Implement the generic trusted transaction protocol for consequential writes so models can prepare actions but deterministic software owns authority, commit and receipts.
## Scope
- Effect classification for reads/local writes/external compensatable/irreversible-or-uncertain actions.
- Canonical `ActionProposal` including provider/account/target/args/source version/risk/expiry/expected outcome.
- Canonical proposal digest and trusted `Approval` binding.
- Approval limits: recipient/audience, amount/ceiling, destination, time, account and task.
- Prepare → refresh → approve → commit transitions.
- Unique operation ID persisted before dispatch.
- `Receipt` record for provider reference, observed outcome and verification state.
## Security/correctness rules
- Material argument/source/quote changes invalidate approval.
- Approval from another action/conversation/task cannot be reused opportunistically.
- Model/provider confirmation never substitutes for a broker decision.
## Acceptance criteria
- [ ] Modified/expired/stale proposals cannot execute under an old approval.
- [ ] Every attempted consequential write has a durable pre-dispatch operation ID.
- [ ] Exact account/target/recipient/amount/audience are shown on trusted approval surfaces.
- [ ] Commit requires a valid capability/grant and bound approval according to policy.
- [ ] Provider result is stored separately from independent verification state.
- [ ] Approval replay/cross-account/cross-recipient attack fixtures fail closed.
## Dependencies
- SEC-02
- CORE-02
- CONN-01
**First phase:** P1
**Maturity target:** P4
**Owner:** platform/security
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading programme #1, epic #26, and dependencies SEC-02, CORE-02, and CONN-01 to understand the surrounding protocol and security requirements. Use the listed acceptance criteria as the completion checklist, including fail-closed replay, cross-account, and cross-recipient fixtures; the issue names no files or tests to run.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend-api-design, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100