feat: implement committee decision workspace

This commit is contained in:
2026-08-01 17:48:25 +02:00
parent 232329ac52
commit 758b59ca03
28 changed files with 4909 additions and 32 deletions
+58 -8
View File
@@ -9,7 +9,7 @@ Committee, board, council, and senate workflows for meetings, agendas, minutes,
- committee bodies
- meeting agendas
- minutes
- decision records
- deliberation and vote context plus references to formal decision records
- votes
- follow-up assignments
@@ -18,6 +18,9 @@ Committee, board, council, and senate workflows for meetings, agendas, minutes,
- generic task execution
- document storage
- calendar event storage
- generic approval gates
- the cross-domain formal decision lifecycle, including authority, facts,
applicable rules, reasoning, effects, review, correction, and revocation
## Integration Candidates
@@ -28,19 +31,66 @@ Committee, board, council, and senate workflows for meetings, agendas, minutes,
- workflow
- approvals
## Seed State
## Current Persistent Backend Slice
The current repository state is intentionally small:
The current repository state is intentionally bounded:
- module manifest and entry point
- tenant-level permission definitions
- manager and viewer role templates
- documentation topic describing the module boundary
- documentation topic and architecture/evidence declaration
- `committee.workspace` and `committee.decision_path` interfaces and capabilities
- tenant-scoped body, meeting, agenda-item, vote-result, and minute persistence
- immutable revisions, OCC, replay-safe lifecycle events, migrations, uninstall
guards, API routes, and tenant summary counts
- a governed assembler for one formal committee outcome
- a protected local Decision projection when the optional Decisions provider is
absent
- a three-pane `/committee` workspace for bodies, meetings, agendas, governed
vote results, and minutes
- a provider-neutral ballot-finalization contract for external and secret
ballots that retains aggregate evidence rather than individual ballots
- Gitea issue workflow templates
- manifest contract test
- manifest and decision reconstruction contract tests
No runtime API, database model, migration, WebUI route, or navigation item is registered yet. The first implementation slice should preserve the boundary above and only add user-visible surfaces once the workflow model is clear.
The decision path accepts or resolves one effective
Mandate covering the deciding unit, function, and jurisdiction; requires
approval, fact evidence, versioned legal bases, operative
result, and reasoning, and emits the shared formal Decision contract. If a
Decision registry is installed it records there; otherwise the result is
retained in the Committee-owned fallback projection and is available only
through the protected-read permission.
## First Implementation Slice
The workspace records the result of a governed vote rather than becoming a
general remote-balloting system. Local closure requires unique choices,
eligible/cast counts, matching result counts, an explicit quorum result, an
Approval reference, and evidence. Decided agenda items require a formal
Decision reference, and meetings cannot close while agenda items remain
unfinished. Accepted or corrected minutes require a Records reference,
Approval, and evidence.
Define committee body, meeting, agenda item, decision, vote, minute, and follow-up task references.
A provider-bound vote is finalized only through
`committee.ballot_adapter.<provider>`. The adapter receives tenant, vote,
choices, eligible count, external ballot reference, request time, and
idempotency key. Its result must cover exactly the configured choices, sum to
the cast count, stay within eligibility, carry same-tenant evidence, and supply
a lowercase SHA-256 result digest plus provider receipt. Committee persists
that aggregate and does not persist voter choices or provider credentials.
Database restore is the module's semantic recovery unit. Calendar events,
documents, records, tasks, approvals, and externally conducted votes remain
recoverable through their owning providers and are linked by stable references.
## Decision Reconstruction Proof
`tests/test_decision_path.py` proves effective-time authority, organization,
function, and jurisdiction coverage, approval, legal basis/evidence versions, requested effects,
information governance, responsible actor/automation assurance, and a protected
reconstruction payload. A vote remains
an approval reference and is not made indistinguishable from the formal
institutional outcome.
`tests/test_workspace.py` proves parent and lifecycle constraints, immutable
history, replay and stale-write rejection, tenant isolation, committed-only
events, vote/quorum evidence, adapter-only provider closure, aggregate-only
secret-ballot persistence, minutes, and the local Decision projection.