brigade-admin

• SKILL.mdcore · 19,311 bytes
• SKILL.mdcore · 19,311 bytes
• SKILL.mdcore · 19,311 bytes
• SKILL.mdcore · 19,311 bytes
• SKILL.mdcore · 19,311 bytes
• SKILL.mdcore · 19,311 bytes
• reference/lifecycle.mddoc · 5,011 bytes
• reference/rulings.mddoc · 9,595 bytes

# Brigade admin

The executive admin is one thread that works for the user on one repository. As an assistant, it keeps the user up to date across every coordinator there, forwards requests, files shared intake once, and writes one plain-language update. As a coordinator of coordinators, it settles conflicts between them on its own authority, by the rules in [Rulings](#rulings), and logs every ruling so the user can review and overrule it. It escalates only what the rules cannot settle. The scripts enforce. The cap stays in `land.py`, paths stay exclusive through leases, and each ruling is carried out by a script. The user sets the rules' inputs, answers every decision, and has the last word. Each coordinator keeps its own work, reviews, queue entries, and `menu.md`. Without an admin, every coordinator works as [the brigade skill](../brigade/SKILL.md) says.

Its store is `<store>/<project>/.admin/`, beside the coordinators it serves, with `role: "admin"` in `restaurant.json`. It is a sibling of each of them, so intake ownership, `ticket move`, and handoff ids work as for any sibling. An admin thread follows this skill, and [Filing tracker work](../brigade/SKILL.md#filing-tracker-work) and [Digest messages](../brigade/SKILL.md#digest-messages) in the brigade skill. That skill's [Open a restaurant](../brigade/SKILL.md#open-a-restaurant), [First service](../brigade/SKILL.md#first-service), [Run a service](../brigade/SKILL.md#run-a-service), [Liveness check](../brigade/SKILL.md#liveness-check), and [Git and PR housekeeping](../brigade/SKILL.md#git-and-pr-housekeeping) are for coordinators. The admin runs the brigade skill's script, [`../brigade/scripts/brigade.py`](../brigade/scripts/brigade.py) from this file, so `<skills>` is the directory that holds both skills. Read that skill's [Terms](../brigade/SKILL.md#terms), [The script](../brigade/SKILL.md#the-script), and [Reporting to an executive admin](../brigade/SKILL.md#reporting-to-an-executive-admin) sections before the first command. The first two define the store's files, `$L`, the owner token, and each command the block below does not list. The third holds the coordinator's side of each line and each ruling. Here `$B` is `python3 <skills>/brigade/scripts/brigade.py --at <store>/<project>/.admin --owner <thread>@<generation>`. Drop `--owner` on `set --thread`, per [The script](../brigade/SKILL.md#the-script). Opening step 4 runs before any thread is recorded, so it also drops `--owner`. Read [lifecycle](reference/lifecycle.md) for store paths before opening.

```bash
python3 <skills>/brigade/scripts/brigade.py open --admin --project-root <root> --reporting <level>   # opened or exists, then every coordinator on the root
$B request --to <coordinator> "<line>"     # records A<n>, publishes it into that inbox, prints the thread to tell
$B request --republish                     # publishes again any request a crash left unwritten that its coordinator has not finished
$B rule add --kind contested-paths|ownership|shares|queue-order --parties <a>,<b> --question "..." --rule purpose|priority|age|related-work|dependency|floor|user --decision "..." [--supersedes R<n>]   # prints R<n>
$B rule overrule R<n> --decision "<the user's words>"   # marks it overruled and records the user's ruling
$B rule set R<n> --state done|expired ; $B rule list [--state in-force]
$B sync                                    # copies each coordinator's new log.tsv rows into this log, or prints nothing new