← Documentation

The restricted view

Part of team usage — which caller reads the full or the restricted view, and the closed list of fields the restricted view carries.

Which view a caller reads

One function decides the view, once (viewFor, information/usage.ts), and every line below — the text and --json alike — is rendered from the one report it builds:

  • The owner at a terminal reads the full view: every team named, every root carried, every team's own rows, every problem in the words its own read produced.
  • Every other caller reads the restricted view.

That comparison is deliberate, and it is fail-closed: a process that double-forks out of the herdr tree walks to no herdr ancestor and is placed as the owner without a terminal (owner-no-tty) — the placement a forged ancestry would produce; a caller the walk places as the owner without a terminal is nevertheless admitted to launch seats by mayLaunchSeats. While the walk cannot tell a real detached owner from a detached stranger, every caller but the owner at a terminal reads the restricted view, a detached owner's own runs included; the day placement is trustworthy, this one comparison flips and nothing else changes. The per-team widening field (owner | seats) is not read by this build: a team's route to the full view is not built yet.

The rule that anyone may run it, from any folder, is on the team usage page.

What the restricted view carries

The restricted view is a closed list of fields, built once by reportOf (information/usage.ts) before either renderer runs and rendered by the one renderer both views share, so the text and --json can never disagree. Nothing a read of another team produced crosses it: no name, no root, no path, no message. Specifically, it never carries

  • another team's name — a machine line's team, a row's, a note's scope (read by another team, another team: …) — nor another team's root, which is a path this tool derived from the machine;
  • another team's rows: only the caller's own team's rows print under a machine line;
  • another team's pace: a machine line whose newest reading is another team's carries no pace element at all — null in --json, absent from the text — so a withheld figure never reads as a failed computation, while the caller's own rows keep their pace;
  • another team's problems in their own words: a store's own message becomes the fixed sentence a store on this machine cannot be read: the owner reads the reason, and a team's problem becomes one fixed sentence per kind, counted;
  • the seat on another team's machine line (a seat name is the caller's own team's material);
  • and any figure of an account the caller's own file does not name — such an account is counted in the lab's others and never given a line, a figure or a why.

Five things the design called droppable are carried on purpose, and each is one field with its own test:

  • the machine's counts (counts): one team's machine and four teams' machines are different situations, and the count of teams is not a name;
  • whether a line's figure is the caller's own or another team's (machine.other; in the text, the words read by another team) and the age it was read at (machine.age) — the reader decides on the figure, so the reader is told what it is;
  • the watch clause (machine.watch): a reader deciding off a figure needs to know whether a watch is refreshing it;
  • the count on an anonymized note (notes[].count, 2 teams' states cannot be read …): one team's problem and four teams' problems are different situations;
  • the full age — 2m, not a few minutes ago: the moment is what the figure's age is computed from, and rounding it would take a decision away from the reader.

What else the restricted view prints of the caller's own team is its own: the project name from the copy in force (a live project: edit after approval is not shown), the loader's problems as fixed sentences, the state's own reason with this project's own path relative to its root, and the note: lines above. A file that does not load reads, one note per distinct line,

note: .agents/team.yaml does not load (line 4): run team status for the reason

a file that cannot be read reads .agents/team.yaml cannot be read: the owner reads the reason, and a state that cannot be read reads the tool's own reason with the project's own relative path (.agents/team.state.json is not valid JSON; move it aside and run the command again). A refused approval — a record in the store that does not verify for this project — reads one fixed sentence in place of the store's own words, which carry absolute paths:

note: the approval on this machine does not verify for this project: the owner runs `team approve`

The earlier note: lines this names are on the reads-and-writes page and the report page.

The two faces, by example

The same command run by the owner at a terminal prints the same text on this one-team machine — the two faces differ in the text only when another team's names are allowed in — and --json with "view": "full", "team": "beacon" on every machine line and "root": "." on every row.

A machine that holds other teams reads the same header, with their teams counted and their labs counted where the caller's own team carries them: an account their files declare and the caller's does not is counted in the lab's others (anthropic: 2 other accounts) and never given a line, a figure or a why; a machine line whose newest figure is theirs reads read by another team, 2m ago; and whatever their reads could not answer is one fixed sentence per kind, counted (note: 2 teams' states cannot be read (not valid JSON; move it aside and run the command again)). Nothing a read of theirs produced crosses — no name, no root, no path, no message — and that is the whole of what this page's restricted sections promise.

The restricted text and the JSON these name are on the team usage page and the JSON page.