Crate pma_core 

pma’s core: the store, scanning, dispatch and workflows, and the api module its front ends share. It prints nothing and depends on no UI crate. Design: docs/dev/design.md, docs/dev/frontends.md.

Modules

accept

What a ready run’s recorded gates amount to. The reasons a run needs a human are computed from the run, never stored, so changing a rule re-reads the evidence rather than trusting a verdict recorded under rules nobody can name any more.

agent

Runs a coding agent, and then the project’s verify command, in a worktree.

api

What a front end may read and do: Query returns a View of plain data, and Action returns an Outcome. The CLI, the TUI and the web each render these, so a front end that matches every variant cannot fall behind another. Design: docs/dev/frontends.md.

class

Maintenance class of a task: what an agent may take, and which paths a correct change touches. The class is predicted at dispatch from the signal type and the item’s tags; the paths a run actually changed are checked against scope afterwards, so a misprediction cannot widen the scope.

complexity

Deterministic complexity, 1 to 5, from features a scan and a dispatch already know. No model is called.

config

Configuration: built-in defaults plus overrides stored in the database, addressed by flat keys such as tiers.2, signals.ci or projects.cyllama.verify.

dates

Calendar days as integers: days since 1970-01-01, in UTC.

deps

Outdated dependencies, per ecosystem, as each tool reports them.

dispatch

Dispatch and review: a worktree per task, agent runs within the batch budget, verification by pma itself, and the review actions.

jobs

Jobs: a pma command queued to run detached. --detach stores the command’s arguments and starts a runner unless one holds runner.lock. The runner runs each job as a child pma, oldest first, and exits once the queue is empty. Design: docs/dev/async_dispatch.md.

keys

The one key table every front end reads: which key opens which tab, moves the selection, or does which action. Keys are DOM KeyboardEvent.key names (j, Enter, Escape, ArrowDown), so the web uses the table as it is and the TUI maps its key codes to the same names. Plain keys only: a browser or screen reader reserves most combinations with a modifier.

next

pma next: what should happen next, and who does it. One ordered list for agents, in the order pma dispatch --auto takes it, and one for you: runs waiting on a decision, then tasks no agent may take that are critical or urgent.

pass

One pass over a workflow instance: write the argument bag, derive what is ready, run what a rule decides, and run an agent only under a plan the developer approved by its id.

progress

A one-line progress bar on stderr, for pma scan.

projects

The hand-set half of a project’s record – its tier and its tags – as a file, so a portfolio is retiered in one edit rather than one command per project. Everything else in the record is written by a scan.

publish

Publishing approved runs, one of two ways, each its own command: pma push commits a run and pushes it to the default branch, and pma pr commits it and opens a pull request. Both remove the worktree afterwards. A run with a pull request stays pr-open, holding its task, until the pull request is merged or closed. A third way, land_local, writes a verified run into its clone as unstaged changes and commits nothing.

rank

Places tasks in the Eisenhower matrix and orders projects by what needs attention.

report

Text output for pma matrix and pma status.

report_runs

pma report: what dispatching has actually produced. Reads runs and attempts only, so it describes work that was attempted. It says nothing about repositories where nothing was ever dispatched; pma status is still what covers those.

route

Routing policy: which worker and model take a task, and how much autonomy the result gets. The policy is an artifact, not a judgment per task. One decision per revision, applied deterministically to every dispatch.

scan

Collects facts about each project: open TODO.md items with their age, local git state, the last commit that counts as activity, and CI status.

screen

A View as an interactive front end shows it: tables of rows to select, or a detail of fields and sections; and how a key on a selected row becomes an Action. The TUI and the web both draw a Screen and send what action builds, so neither decides for itself what a row is, what a key does to it, or what a state means. Each cell carries a Tone, so both colour a failed run or a critical task alike.

script

Workflow documents written as Rhai scripts.

settings

settings.toml: the configuration a user edits. It holds the config keys, roots, workers, presets and each project’s tier and tags. The store’s tables of the same names mirror it, so queries keep their joins; the file wins. Workflow and route revisions stay in the store, since activating one is a gate a hand edit would skip.

store

The portfolio database: roots, projects with tiers, settings, the results of the last scan, agent runs, and portfolio notes.

sync

Hybrid sync between Critical items in TODO.md and GitHub Issues.

todo

Parser and linter for the TODO.md format, v2.

watch

pma watch: what running agents are doing, read from their logs. The runner observes; no agent reports. A claude log is stream-json, one record per event; any other worker’s log is shown by its last line.

worker

A coding agent as a record rather than a code path: how its prompt and directory are passed, how a model is named, whether a budget cap exists, how success and cost are read back, and whether it has a sandbox or a command allowlist.

workflow

A workflow is a typed, parameterised function over bags of units: a graph of nodes, each applying one of five primitives or another workflow, joined by edges that decide where a unit goes next.