CLI reference¶

Generated from the command definitions. Every command takes --root PATH (default: the git top-level of the working directory).

activities¶

GDPR processing activities: purpose, legal basis, and what they touch.

activities add¶

Add touchpoints (unit:id) to an existing activity.

activities create¶

Create an activity; unknown fields become !todo.

activities explain¶

Show an activity's manifest, its touchpoint graph and the derivation.

activities list¶

List the activities with their derived data, categories and DPIA verdict.

activities set¶

Change facts about an activity (the answers to its !todo questions).

app¶

The product itself: name, description, controller, processor, scale.

app set¶

Change facts about the product (the answers to its !todo questions).

app show¶

Everything declared about the product.

challenge¶

Re-open the reviews a change undermines (the challenger agent alone).

The agent reads git diff BASE..HEAD, asks what reviewers asserted about the changed files, and puts the doubtful items back to pending with grounds. It never reclassifies. Exit 1 when it challenged something, 0 otherwise.

check¶

The compliance to-do list: what has to happen next, grouped by kind.

Errors (fix the files) exit 3. Missing (established non-compliance, never ignorable), Todo (questions for a human; --allow-todo waves them) and Review (run the agents) exit 1. 4 is a crash of model-wtf itself.

data¶

Inventory and classify the application's data.

data auto-review¶

Have an OpenCode agent review every pending data item.

Runs OpenCode in an isolated configuration (throwaway HOME, generated config, read-only tools, our MCP server as the only write path), in rounds, until nothing is pending. The provider is the prefix of --model: OpenRouter (OPENROUTER_API_KEY), Scaleway Generative APIs (SCALEWAY_SECRET_KEY) or a Scaleway dedicated deployment (SCALEWAY_SECRET_KEY + SCALEWAY_INFERENCE_ENDPOINT). Exit 0 when complete, 1 when items remain, 4 when OpenCode or the provider's key is missing.

data contents¶

Declare what a JSON-like column holds, one ENTRY per kind of information.

ITEM_ID is <unit>:<app.Model.field> of a JSONField/ArrayField/HStoreField. Each ENTRY is name=pii,sensitivity,category (name=yes,personal,contact); the names are identifiers, not JSON paths. --unknown none with no entry declares an empty, harmless blob.

data list¶

List every data item of every unit with its classification.

data override¶

Record an override of a field's classification.

ITEM_ID is <unit>:<app.Model.field> (the unit prefix may be omitted when the repo has one unit). An existing row is never rewritten.

data reviewed¶

Mark data items as reviewed by a human.

ITEM_IDS are <unit>:<app.Model.field> (unit prefix optional with one unit). The current classification is what is being confirmed.

data rights¶

Record what is true of one right on one personal item.

ITEM_ID is <unit>:<app.Model.field> (@json/@files rows and a <app.Model>.* glob for every personal field of a model are allowed). --exempt GROUND explains why the right is not served (an order kept for accounting: erase --exempt legal_obligation --note "..."); --missing declares the gap; --clear removes the entry. Other columns of the row are untouched.

data rules¶

Show the built-in data rules in evaluation order.

data why¶

Who needs a data item: the touchpoints handling it, the activities holding it.

PATTERNS are unit:id ids, globs allowed (api:people.Person.*).

flows¶

Where the data goes: every flow, its kind, status and payload.

flows list¶

The flows, one per line; filters narrow by touchpoint, kind or status.

flows show¶

One flow: ends, kind, status, items, and the threat cells on it.

FLOW_ID is source->sink as flows list prints it, or a touchpoint id to show all of its flows.

ghate¶

The pull-request gate: fail only on findings the change introduces.

Runs compliance check on the base (in a temporary worktree) and on the head, compares by finding identity. With an API key, the challenger agent first reads the diff and re-opens the reviews it undermines, which then count as introduced. Exit 0 when nothing is introduced (pre-existing findings are listed, not failed), 1 when something is, 3 on declaration errors in the head, 4 on a tool error.

init¶

Create compliance.db (app, parties) and wire the units.

Missing values are prompted for on a terminal; the processor defaults to default_processor from ~/.config/model-wtf/config.yml. Never overwrites anything: re-run to add what is missing.

parties¶

The organisations data is sent to: list, inspect, fix, merge.

parties add¶

Declare a party; contact facts not given are left !todo.

PARTY_ID defaults to a slug of --name. Refused when it looks like an existing party (say --distinct-from ID when you know it is not) or names a store of the project (mail, error monitoring: those are stores).

parties distinct¶

Record that PARTY_ID and each of OTHERS are different organisations (Mailgun and Mailjet): the lookalike report stops for those pairs.

parties duplicates¶

Pairs of declared parties that look like one organisation; with CANDIDATE (and --name/--website), what a party by that id would clash with.

parties list¶

List the declared parties; lookalike pairs are reported underneath.

parties merge¶

Fold LOSERS into --into: transfers, recipients, roles and stamps move, the winner's !todo facts take the losers' answers, the losers go.

parties remove¶

Delete a party nothing refers to (else: parties merge it, or --force).

parties set¶

Change facts about a party (the answers to its !todo questions).

parties show¶

Everything declared about one party and everything that refers to it.

parties to-flow¶

PARTY_ID was the project itself (its own endpoint, a service name): nothing leaves. The transfers to it go — the edge is the calls flow the code shows — and so does the party.

parties to-store¶

PARTY_ID was infrastructure (mail, Sentry, the project's own service): its transfers become writes to STORE_ID (unit:slug), the party goes.

stores¶

Where the data lives: databases, caches, buckets, queues.

stores add¶

Declare a store the settings do not show (<unit>:<slug>).

Refused when a store of the unit looks the same (shared host, alike name or slug) unless --distinct-from names it.

stores distinct¶

Record that STORE_ID and each of OTHERS (slugs of the same unit) are different stores: the lookalike report stops for those pairs.

stores explain¶

Show where a store comes from and which data items reference it.

STORE_ID is <unit>:<slug> (the unit prefix may be omitted when the repo has one unit).

stores list¶

List the stores of every unit with how many data items each holds.

stores merge¶

Fold LOSERS (unit:slug) into --into (a slug of the same unit): writes, item placements and stamps move, the losers go.

stores remove¶

Delete a declared store row (else: stores merge it, or --force).

stores set¶

Change facts about a store; a row is created for a config store.

threats¶

The threat matrix: every touchpoint, store and flow against pytm's catalogue.

threats auto-review¶

Have agents stamp the open threat cells.

Each reviewer reads the code and calls threat_stamp per open SID: mitigated (with file:line), n/a, accepted, or a missing finding. Same sandbox and exit codes as the other auto-reviews.

threats findings¶

Every !missing threat stamp, most severe first.

Severity is impact (effect x degree x sensitivity) x likelihood (the most feared actor who can reach the touchpoint); see the README. Findings stamped before weighing existed show as unweighed.

threats matrix¶

Counts per element kind, per threat and per topic; --open lists the cells.

A cell is never (impossible in the stack), dismissed (a simple rule closed it for that element) or open (an agent has to look).

threats stamp¶

Stamp one open threat cell on a touchpoint, store, party or flow.

Records the stamp on the element (a flow's on its source touchpoint, keyed SID@sink). Pinned to the element's fingerprint: when the code moves, the stamp goes stale and the cell reopens.

threats why¶

Every threat for one element (a touchpoint id, unit:store, party:x, or a flow a->b) with in/out and the rule that decided it. A finding id (F-0042) shows that one finding in full.

touchpoints¶

Entry points through which data flows: routes, tasks, admin screens.

touchpoints auto-review¶

Have an OpenCode agent declare what each touchpoint handles, then group.

Pass 1 reviews pending touchpoints one at a time (reading the view or task code, referencing inventory items, adding transient manual items when the code handles personal data that is never persisted). Pass 2, once nothing is pending, groups every PII-touching touchpoint into processing activities following the front -> api -> task edges; fields the agent cannot know stay !todo. Same sandbox and exit codes as data auto-review.

touchpoints list¶

List every touchpoint with what it handles and which activity holds it.

touchpoints set-data¶

Declare the data items a touchpoint handles.

REFS are <unit>:<app.Model.field> data ids (@json/@files rows allowed; a ref without unit means the touchpoint's unit). ref=<ops> states what the code does to the item: ref=create, ref=create,read, ref='{erase: {by: subject}}'; a bare ref is a read. No REF at all declares an empty list: "touches no inventory item, checked".

touchpoints show¶

Everything known about one touchpoint: facts, schemas, manifest, activities.

TOUCHPOINT_ID is <unit>:<id>.