Metadata-Version: 2.4
Name: govoplan-cases
Version: 0.1.23
Summary: GovOPlaN administrative case context module.
Author: GovOPlaN
Requires-Python: >=3.12
Description-Content-Type: text/markdown
Requires-Dist: govoplan-core>=0.1.30

# govoplan-cases

<!-- govoplan-repository-type:start -->
**Repository type:** module (domain).
<!-- govoplan-repository-type:end -->

`govoplan-cases` owns formal administrative case context for GovOPlaN.

The module should stay focused on case identity, lifecycle state, assignments,
deadlines, participants, evidence links, and case-level audit context. It should
not own forms, files, workflow execution, task queues, templates, payments, or
mail delivery; those are integrated through GovOPlaN capabilities, events,
commands, and DTOs.

The executable backend slice now exposes:

- `cases.service_intake`, which converts one published, effective Service
  definition into a case intake plan while retaining the exact service,
  mandate, jurisdiction, legal-basis, form, workflow, result, evidence, and
  deadline references; and
- `cases.party_context`, which consumes an optional procedure-party provider
  or a bounded Cases-only compatibility projection and emits policy-filtered,
  frozen contact snapshot references for downstream delivery; and
- `cases.registry` plus `/api/v1/cases`, which persist tenant-local case/status
  catalogs, stable case identities, immutable OCC-guarded revisions, stable
  assignment/evidence/Decision/record references, and replay-safe lifecycle
  events; and
- `cases.service_launcher`, which opens exactly one deterministic case from an
  exact published Service revision and safely replays the same Portal launch;
  and
- `tickets.case_escalation`, which creates exactly one formal Case from an
  authorized Ticket handoff while preserving a governed Ticket reference.

Cases does not own institutional Service, Party, representation, identity,
address, Mandate, Decision, file, workflow, or task lifecycles. The `/cases`
workspace now supplies list/detail, status/title revision, history, and timeline
surfaces. A case can remain tenant-visible or become restricted. Restricted
access requires a current custodian, explicit subject, or assignment-derived
grant whose permission and exact allowed purpose both match the operation.
`cases.casework` is the interactive default and `cases.search` is reserved for
Search rechecks. The detail surface uses the shared reference selector to
manage grants and purposes; list, detail, history, timeline, update, evidence,
Decision, Search, and Records-source paths apply the same fail-closed decision.
Current grants also govern historical revision reads.

See [docs/CONCEPT.md](docs/CONCEPT.md) for the current module concept.

## Data-subject requests

Cases contributes `privacy.dsar.cases`. It reports exact-tenant access grants,
including their bounded allowed purposes,
and operator attribution, plus minimized case lifecycle data when an explicit
Cases reference is supplied and corroborated. Raw snapshots, metadata, search
text, free-text reasons, event payloads, evidence identifiers, request digests,
idempotency keys, audit internals, and unrelated access subjects are excluded.
Historical case evidence is retained; current open case and active access facts
require authorized manual review through the existing lifecycle. Applicant
identity correlation remains a Parties responsibility and is never guessed
from a case's party references.

## Ticket escalation

When Tickets requests escalation, Cases rechecks tenant membership and
`cases:case:create`, resolves the exact active Case type and its initial status,
and derives a deterministic Case ID from the Ticket and idempotency key. A retry
returns the same Case. The Case keeps only the stable Ticket reference, source
revision, number, and authorized handoff note in governed context; it does not
copy Ticket comments, attachments, participants, or lifecycle state. If Cases
is absent or the configured type is unavailable, Tickets remains usable and
shows the integration consequence to the operator.
