Tares

Write an observation back to Tares's agent-memory lane. It becomes a source like any other: joined into correlated reads, so what you learned this incident appears in the timeline next time the same key acts up. memory_type: observation | aggregation | decision.

Keep one thing you learned about this project (for example "tests need the dev database running") in its memory, dated and signed; every session on the project reads it. A rule worth keeping for every project goes to the orchestrator instead (an FYI); only it adds to the shared memory.

Start every review here: the pull request as GitHub has it (it says STOP when the PR is merged or its head moved past `head`), the ticket and its working doc, the builder's checks compared with its recorded session (unmatched first: check those yourself), Codex's findings and the waivers to judge, earlier rounds and their open findings, assumptions and decisions, and what keeps coming back in this repo. Then review to your own bar.

The pull requests waiting for review across every project, in the order to take them: those blocking their milestone first, then the longest waiting. Each says whether the builder's Codex layer is clean and whether an earlier verdict is for an older commit.

Save the crew's settings the person chose (only the ones given change). Only the person's own session or the orchestrator may. `idle_wake` true has the watch wake idle stations when they have work, instead of each ticking on its own. `pace` true slows the crew before the plan's limits are hit.

Mark this Claude Code session as running a named flow, e.g. "challenger" (a second model challenges your plan and every commit; Tares keeps the whole exchange and writes the session summary). Pass an empty string to clear it. Call it when the user asks for the flow at the start of a session. This tool only acknowledges: the Tares plugin sees the call in the transcript and marks the session on both the laptop and Tares.

Move a ticket you hold: `stage` is doing (you started), review (its PR is up: pass `pr`, the pull request's URL), changes (the reviewer asked for changes), merged, or blocked (say why in `reason`). Only the releaser marks a ticket shipped. A ticket held by another station is refused; ask the orchestrator. For a ticket that lives in Linear or GitHub, also move it there (Linear's own tools, `gh` for GitHub). Name your branch factory/<ticket> (factory/T3) so Tares finds the pull request on its own too. Asking for review, pass the checks you ran as `checks` ([{command, result, commit, broke_test}, ...]) instead of one add_check call each; they are recorded before the stage moves.

Profile a source's real fields from recent events: every candidate field with its coverage, distinct count, and top values, plus which are already declared as labels/keys. Call this BEFORE choosing labels for a source — a label's `field` MUST be one of these exact field names (never invent one). The `labels` block echoes the source's current declared axes.

Counts per value of the label `by` over the project's sources, the last `window` against the window before, largest change first. `where` {label: value} narrows the events counted, `sources` narrows the sources. Use it to see what moved before reading one entity.

Register a webhook to be woken (pushed) when a trigger fires. Returns a subscription id.

Dry-run a source config without creating it: poll connectors do one live poll and return a sample; push connectors return their ingest endpoint. Use before create_source to check the config works.

Edit an EXISTING trigger in place: replace its sources, filters, key_field, condition, emit and cooldown, and move it to another `project` when given. Create new triggers with create_trigger(); this only updates one that already exists (renaming isn't supported, so keep `name` the same). `description` left out keeps the current one, "" clears it. See create_trigger for the shapes.

Write a markdown doc into the project, or replace one when `id` is given. `kind` is one of: `start` (the prompt a session that builds the project starts with: what to read first, which ticket to take, how to work), `spec` (what is built and why), `plan` (milestones and the order of work), `agents` (the AGENTS.md of the build: conventions, commands, how to test), `working` (the working doc of one ticket: context, steps, files likely touched, how to verify; link it with attach_working_doc), `note` (anything else). Working docs and every other doc stay in Tares; they never go to Linear or GitHub. A rule or fact that holds for every project goes in the shared docs with add_to_global instead. Returns the doc's id.

Write one of the project's milestones, or change it when one with this `name` exists (names are unique). Each milestone ships something a person can check: `goal` says what in one line, `checks` are its acceptance checks, [{"check": "<command or short manual step>", "expect": "<what it should show>"}], that the releaser runs when the milestone ships. `position` orders them (a new one goes last). To rename one, pass its current name or id as `id` and the new `name`. Give tickets a milestone with write_ticket(milestone=<name>). When the project's tickets live in Linear or GitHub, its milestones come from there (for GitHub, the milestones its issues sit in): add and rename them there and write only the goal and checks here.

Write the map of a GitHub repo (owner/name) that the builder and reviewer briefs serve: layout, entry points, how to install, build, test and lint, conventions, the files tickets touch most, known traps. One map per repo, shared by every project on it, at most 8,000 characters (about 2,000 tokens). `body` replaces the whole map, so start from the one in your brief and pass its `version` as `base` (leave it empty when the repo has no map). If someone wrote the map since, nothing is written and the answer is the map now: fold your change into it and write again. `note` says what changed and becomes a dated line in its history. Write it when the brief says the repo has none; update it when a merged PR changes the layout or the build, test or lint commands.

Add a ticket to the project's list, or change one when `id` is given (its id or T<n>). Only for a project whose tickets live in Tares: when they live in Linear or GitHub, create and change them there (milestones and "blocks" or "blocked by" relations included; `gh` for GitHub) and Tares picks them up on its next sync. `status` is todo, in_progress, done or canceled; `position` orders the list (a new ticket goes to the end); `milestone` is the name of a milestone written with write_milestone ("" takes it out of its milestone); `depends_on` lists the tickets (T<n> or id) that must be done first ([] clears them); `repo` is the GitHub repo the ticket changes (owner/name), for a project that spans several repos ("" clears it; a Linear or GitHub ticket takes only this, and attach_working_doc). Returns the ticket with its label (T<n>).