Files
govoplan-committee/README.md
T

103 lines
3.8 KiB
Markdown

# GovOPlaN Committee
<!-- govoplan-repository-type:start -->
**Repository type:** module (domain).
<!-- govoplan-repository-type:end -->
`govoplan-committee` is the GovOPlaN module for committee, board, council, and senate workflows for meetings, agendas, minutes, deliberation, voting, formal decision references, and follow-up tasks.
The backend now exposes versioned `committee.workspace` and
`committee.decision_path` capabilities. The workspace persists immutable,
OCC-guarded revisions for bodies, meetings, agenda items, governed vote
results, and minutes, with replay-safe lifecycle events. The decision path
combines that committee context with an effective Mandate,
including organization, function, and jurisdiction coverage, with approval,
legal bases, evidence, reasoning, and effects to create the shared
formal Decision contract. Mandate resolution and Decision persistence remain
optional providers. If Decisions is absent, Committee retains a bounded,
protected local Decision projection so the outcome remains reconstructable.
The `/committee` WebUI provides the body, meeting, agenda, vote, and minutes
workspace using the same immutable revisions and lifecycle guards as the API.
When Voting is installed, Committee creates and follows a governed
`voting.ballots` record while retaining only its meeting/agendum reference and
verified aggregate outcome. Voting owns the frozen electorate, casting,
tallying, certification, challenge, and annulment lifecycle. The older
`committee.ballot_finalizer` / `committee.ballot_adapter.<provider>` path
remains a 0.1 compatibility boundary for existing external integrations;
individual provider ballots never enter Committee persistence.
## Initial Ownership
- committee bodies
- meeting agendas
- minutes
- deliberation/vote context and formal decision references
- votes
- follow-up assignments
## Boundaries
This module does not own:
- generic task execution
- document storage
- calendar event storage
- the generic formal decision lifecycle; a future Decisions provider owns
authority, facts/rules, reasoning, effects, review, correction, and revocation
Detailed boundary notes are in [docs/COMMITTEE_DOMAIN_BOUNDARY.md](docs/COMMITTEE_DOMAIN_BOUNDARY.md).
## Integrations
Expected optional integrations:
- calendar
- docs
- files
- tasks
- workflow
- approvals
- voting
## Development Install
From the core checkout:
```bash
cd /mnt/DATA/git/govoplan-core
./.venv/bin/python -m pip install -e ../govoplan-committee
```
Focused manifest verification:
```bash
cd /mnt/DATA/git/govoplan-committee
PYTHONPATH=src:/mnt/DATA/git/govoplan-core/src /mnt/DATA/git/govoplan-core/.venv/bin/python -m unittest discover -s tests
```
## API And Recovery
`/api/v1/committee/workspace/{body|meeting|agenda_item|vote|minute}` supports
bounded list/read/write and immutable history. Writes require an idempotency
key and expected revision after creation. Protected local Decision projections
use a separate read permission. Database restore is the semantic recovery unit;
linked Calendar, Files, Records, Tasks, Approvals, and Decisions objects retain
their own recovery responsibility.
`POST /api/v1/committee/workspace/vote/{vote_id}/finalize-provider` is the 0.1
compatibility effect boundary for an installed ballot adapter. It requires the
`committee:ballot:finalize` permission and preserves provider receipt/hash and
evidence without exposing or persisting individual votes.
## Gitea Workflow
Issue templates are installed under `.gitea/`, and the shared label taxonomy is copied to `docs/gitea-labels.json` with the module label `module/committee`.
From the core checkout, labels can be synced once a local `GITEA_TOKEN` is available:
```bash
cd /mnt/DATA/git/govoplan-core
/mnt/DATA/git/govoplan/tools/gitea/gitea-sync-labels.py --root /mnt/DATA/git/govoplan-committee --apply
```