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 compliance/activities/<slug>.yaml; 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.

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) on OpenRouter, in rounds, until nothing is pending. Exit 0 when complete, 1 when items remain, 4 when OpenCode or OPENROUTER_API_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¶

Create <unit>/compliance/data/<id>.yaml overriding a classification.

ITEM_ID is <unit>:<app.Model.field> (the unit prefix may be omitted when the repo has one unit). Existing files are never rewritten.

data reviewed¶

Mark data items as reviewed by a human (writes data.lock.yaml).

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

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¶

Scaffold compliance/ (app manifest, 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.

stores¶

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

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.

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.

Writes the threats: block of the element's YAML (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 (writes its manifest).

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, as in a manifest: 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>.