mirror of
https://github.com/PR0M3TH3AN/bitgate.git
synced 2026-11-05 04:51:00 +00:00
thePR0M3TH3AN
2beb7a7bb5
Proves the engine did not stay video-specific during extraction. - application adapter contract in core (createApplicationAdapter, evaluateObject, collectTargets): an object names the targets that govern it and the strictest verdict reaching any of them wins, so denying a seller takes their whole catalogue down with no cascade logic in the application - examples/commerce: a marketplace on the public API covering all ten proof-of-fit behaviors the plan requires, including that no core change was needed. One product, one snapshot, four surfaces, four different verdicts. - README, integration guide, per-example README, CHANGELOG, four ADRs, and GPL-3.0-or-later LICENSE (the license was listed in Phase 1 but missing) - checkpoints rewritten to reflect actual state and to say plainly which migration-plan phases belong to the consumer repos rather than here Fixes a real gap found by the proof-of-fit: composeDecisions kept only the first decision's evidence, so an object governed by several targets lost the evidence that drove its verdict. Evidence now merges — counts summed, contributor lists unioned, flags or-ed. 556 tests; lint, typecheck, and per-package type build clean.
36 lines
1.4 KiB
Markdown
36 lines
1.4 KiB
Markdown
# ADR 0001 — Four independent decision dimensions
|
|
|
|
**Status:** accepted
|
|
|
|
## Context
|
|
|
|
The reference application collapsed moderation into a small number of booleans
|
|
(`blurThumbnail`, `hideReason`, `blockAutoplay`), computed in two places that
|
|
overlapped. A commerce consumer needs a state those booleans cannot express: a
|
|
product that is visible, inspectable, downranked, and unbuyable at once.
|
|
|
|
## Decision
|
|
|
|
A decision carries four independent dimensions, each an ordered ladder:
|
|
|
|
- `ranking`: `normal` → `downrank` (with accumulated weight)
|
|
- `visibility`: `allow` → `warn` → `restrict` → `hide` → `deny`
|
|
- `interaction`: `allow` → `require-explicit-action` → `deny`
|
|
- `transaction`: `allow` → `require-review` → `deny` (present only when a
|
|
profile can affect it)
|
|
|
|
Composition takes the ladder maximum per dimension.
|
|
|
|
## Consequences
|
|
|
|
Composition is commutative and associative, so the order decisions arrive in
|
|
cannot change the result — which is what lets an object be evaluated against
|
|
several targets and merged without an ordering rule.
|
|
|
|
Consumers must map dimensions to their own UI rather than reading a boolean.
|
|
That is more work at the call site and is the point: the mapping is application
|
|
policy, and putting it in the engine is how the duplication started.
|
|
|
|
`transaction` is absent rather than `allow` when no profile gate can reach it,
|
|
so a consumer can distinguish "explicitly permitted" from "not governed here".
|