@nanocollective/roster 0.1.0-alpha.1

package/docs/session-workflow.md

@@ -0,0 +1,112 @@
+---
+title: "The session workflow"
+description: "Inputs, secrets, and what runs in what order."
+sidebar_order: 16
+---
+
+# The session workflow
+
+`roster-ops/.github/workflows/session.yaml` is the reusable workflow every staff repo calls.
+It is the framework's file: change it in `templates/ops/` and run `roster upgrade`.
+
+A caller is about forty lines and does nothing but pass arguments.
+
+## Why it lives in the tenant
+
+A reusable workflow in a **private** repo can only be called from inside its own organisation.
+A tenant therefore cannot call the framework's copy. That constraint is what forced the whole
+design, and it turned out better: the framework is never a runtime dependency, so nothing
+breaks if it moves, goes private, or is deleted.
+
+This is also why `roster-ops` needs **Settings -> Actions -> General -> accessible from
+repositories in this organisation**. Without it, callers fail with "workflow not found".
+
+## Inputs
+
+| Input | Type | Default | Means |
+|---|---|---|---|
+| `staff` | string | required | Handle, as in `org.yaml`. |
+| `kind` | string | `daily` | `daily`, `mention` or `pr-mention`. |
+| `ops_repo` | string | required | `owner/name` of the ops repo. |
+| `model` | string | `claude-opus-5` | Passed to the agent, unless the agent resolves its own. |
+| `timeout_minutes` | number | `60` | Job ceiling. |
+| `allowed_tools` | string | `Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch` | Tool permissions, for agents that take them. |
+| `issue_number` | string | `""` | Trigger context. |
+| `comment_id` | string | `""` | Trigger context. |
+| `pr_number` | string | `""` | Trigger context. |
+
+## Secrets
+
+| Secret | Required | Means |
+|---|---|---|
+| `APP_ID` | yes | This staff member's own App. |
+| `APP_PRIVATE_KEY` | yes | |
+| `PUBLIC_APP_ID` | no | The shared public identity. Absent means no product-repo lane. |
+| `PUBLIC_APP_PRIVATE_KEY` | no | |
+| `AGENT_TOKEN` | no | The coding agent's credential. |
+| `CLAUDE_CODE_OAUTH_TOKEN` | no | The name the reference runner has always used. |
+
+Neither credential is required on its own and exactly one must be present. A step checks this
+before any checkout, so a missing credential is an obvious failure rather than an
+authentication error forty lines into a log.
+
+## What it does, in order
+
+1. **Mint the private-tracker token** from the staff member's App.
+2. **Mint the public-repo token**, if a public App was passed.
+3. **React to the request** with eyes, on a `mention` only. Before any checkout, so it lands in
+   seconds. `continue-on-error`: a missing reaction must never cost the answer.
+4. **Check out the ops repo.** It is the only thing that can be cloned without having read a
+   manifest, so it goes first and then says what else to clone.
+5. **Work out what to check out**, by running `runner-plan.mjs`.
+6. **Check out the brain**, full history. The agent reads its own past.
+7. **Check out peers and product repos**, per the plan.
+8. **Set git identity** to the App.
+9. **Check out the PR branch**, on a `pr-mention`.
+10. **Set up Node and pnpm**, if the plan found a `package.json`.
+11. **Compose the prompt**, to a step output and to `.roster-prompt.txt`.
+12. **Check the agent has a credential.**
+13. **Work out which agent runs this**, by running `agents.mjs`.
+14. **Run the session**, by one of two steps: the Action-based reference runner, or the generic
+    CLI one. See [choosing a coding agent](agents.md).
+15. **Say so if the run did not finish.**
+
+## What `runner-plan.mjs` emits
+
+Consumed by later steps as `steps.plan.outputs.*`.
+
+| Output | Example |
+|---|---|
+| `brain_dir` | `technology` |
+| `brain_repo` | `acme/technology` |
+| `org` | `acme` |
+| `peers` | `acme/marketing:marketing` |
+| `products` | `acme/acme-web:acme-web:0` |
+| `needs_node` | `true` |
+| `product_dir` | `acme-web` |
+| `product_repo` | `acme/acme-web` |
+| `package_json` | `acme-web/package.json` |
+
+## What the agent gets
+
+| Variable | |
+|---|---|
+| `GH_TOKEN` | private-tracker token, already authenticated |
+| `PUBLIC_TOKEN` | public product repo token |
+| `AGENT_PROMPT_FILE` | absolute path to the composed prompt |
+| `AGENT_MODEL` | resolved model |
+| `AGENT_TOOLS` | the `allowed_tools` string |
+| *the agent's own* | its credential, under whatever name it declares |
+
+## The checkout shape
+
+```
+.
+├── roster-ops/        the ops repo
+├── technology/        the brain
+├── marketing/         a peer's brain, if declared
+└── acme-web/           a product repo, if declared
+```
+
+Flat, one level. The prompts say so explicitly, because it is one level flatter than a
+developer would assume from reading the docs on their own machine.

package/docs/staff-yaml.md

@@ -0,0 +1,163 @@
+---
+title: "staff.yaml reference"
+description: "Every field in a staff member's manifest."
+sidebar_order: 14
+---
+
+# `staff.yaml` reference
+
+A staff member's manifest: the machine-readable half of their charter. Lives at the root of
+their brain repo.
+
+`roster lint` fails if this and `CHARTER.md` disagree. Same strict YAML subset as
+[`org.yaml`](org-yaml.md).
+
+## A complete example
+
+```yaml
+handle: cto
+name: Chief Technology Officer
+mention: "@cto"
+brain: acme/technology
+status_issue: 15
+
+schedule: "0 7 * * 1-5"
+model: claude-opus-5
+timeout_minutes: 90
+mention_timeout_minutes: 30
+pr_mention_timeout_minutes: 60
+
+bot: acme-cto[bot]
+public_bot: acme-robot[bot]
+public_token_env: PIPWEB_TOKEN
+agent_secret: CLAUDE_CODE_OAUTH_TOKEN
+
+identities:
+  - { app: acme-cto, secret_prefix: CTO, scope: private }
+  - { app: acme-robot, secret_prefix: BOT, scope: public }
+
+works_in:
+  - { repo: acme/acme-web, role: contributor, checkout: true }
+
+peers:
+  - { handle: cmo, brain: acme/marketing, label: from-cto }
+
+surfaces:
+  - { path: memory/, render: memory }
+  - { path: strategy/, render: doc }
+  - { path: assets/, render: gallery }
+  - { path: data/, render: table }
+
+labels:
+  owner: [will, cto, cmo]
+  kind: [decision, setup, build, blocked]
+```
+
+## Identity
+
+| Field | Required | Means |
+|---|---|---|
+| `handle` | yes | Must match `org.yaml`. The composer looks them up by the `org.yaml` one, so a mismatch composes the wrong brain. |
+| `name` | yes | Role name in prose. |
+| `mention` | yes | What wakes them, as in `@cto`. The caller's condition tests for this string. |
+| `brain` | yes | `owner/name` of this repo. Without it nothing can check secrets, labels or runs. |
+| `status_issue` | yes in practice | Number of the pinned status issue. The prompts reference it, so a run cannot compose without it. `roster hire --apply` writes it. |
+
+## Schedule and limits
+
+| Field | Default | Means |
+|---|---|---|
+| `schedule` | none | Cron for the daily run. Rendered into the caller. |
+| `model` | org default | Model id. |
+| `timeout_minutes` | 60 | Ceiling on the daily session. |
+| `mention_timeout_minutes` | 30 | Ceiling on a mention run. |
+| `pr_mention_timeout_minutes` | 60 | Ceiling on a PR-amendment run. |
+
+The three ceilings are separate on purpose. Raising the daily one because sessions have grown
+should not double the budget for a PR amendment. A job killed by a ceiling is reported by
+GitHub as `cancelled`; see [troubleshooting](troubleshooting.md).
+
+**These are the source of truth.** The caller workflow carries a rendered copy, so change the
+manifest and run `roster upgrade`, not the other way round.
+
+## Identities
+
+| Field | Means |
+|---|---|
+| `bot` | Login this staff member posts as on private trackers, as in `acme-cto[bot]`. |
+| `public_bot` | Login it posts as on the public product repo. |
+| `public_token_env` | Environment variable holding the public token inside a run. |
+| `agent_secret` | Repo secret holding the coding agent's credential. |
+| `identities` | One entry per App. |
+
+Each `identities` entry:
+
+| Field | Means |
+|---|---|
+| `app` | The GitHub App slug. Carries the house naming scheme, so it is inferred from a sibling rather than built from the handle. |
+| `secret_prefix` | Secrets are `<prefix>_APP_ID` and `<prefix>_APP_PRIVATE_KEY`. |
+| `scope` | `private` (this staff member's own) or `public` (shared by everybody). |
+
+The public identity is shared deliberately. A bot opening a pull request on a public repo is
+unremarkable; a bot signing itself with a job title is a tell.
+
+**The `[bot]` suffix is how a manifest spells it and not how GitHub reports it.** An issue
+authored by the App has author `acme-cto`. roster normalises this; if you are matching on it
+yourself, strip the suffix.
+
+## Relationships
+
+### `works_in`
+
+Repos this staff member contributes to but does not own.
+
+| Field | Means |
+|---|---|
+| `repo` | `owner/name`. |
+| `role` | Prose. `contributor` in practice. |
+| `checkout` | Whether the runner clones it. |
+
+**The first entry becomes `{{staff.product}}` in prompts.** A staff member with an empty
+`works_in` has no product, and any prompt fragment referring to one must guard with
+`{{#if staff.product}}`.
+
+### `peers`
+
+The other staff members this one files work with.
+
+| Field | Means |
+|---|---|
+| `handle` | Their handle. |
+| `brain` | Their repo. |
+| `label` | The label **this** staff member uses when filing on **that** tracker. |
+
+**The label is not symmetric.** In the CTO's manifest the entry for the CMO carries
+`from-cto`, and that label lives on `acme/marketing`, because that is where the CTO's asks
+land. `roster hire` writes both directions and `roster doctor` checks the label exists on the
+peer's repo, not this one.
+
+## `surfaces`
+
+What this staff member keeps, and how the portal renders it.
+
+| `render` | Shows as |
+|---|---|
+| `memory` | Parsed fact cards |
+| `doc` | Markdown, rendered |
+| `gallery` | Image grid |
+| `table` | CSV as a table |
+| `code` | Monospace, syntax preserved |
+
+A surface is a promise: `roster doctor` warns when one is declared and not on disk.
+
+## `labels`
+
+Labels this staff member expects to exist on its own tracker, grouped for readability. Every
+value across every group is checked by `roster doctor`. An agent applying a label that does not
+exist gets an API error mid-run.
+
+## What `roster upgrade` does to this file
+
+Nothing. It is `scaffold` class: written once by `roster hire`, and yours from that moment.
+A framework change that adds a manifest field will not reach an existing staff member, which is
+a deliberate trade against the risk of merging into a file a working agent has rewritten.

package/docs/troubleshooting.md

@@ -0,0 +1,189 @@
+---
+title: "Troubleshooting"
+description: "Every trap we have actually hit, and what it looks like from the outside."
+sidebar_order: 10
+---
+
+# Troubleshooting
+
+Every trap on this page has actually been hit. Most of them fail in a way that points somewhere
+else, which is why they are worth writing down.
+
+Start with `roster doctor`. It groups by staff member and every finding that is not `ok` says
+what to do about it.
+
+---
+
+## "workflow not found"
+
+**Looks like:** a typo in the `uses:` path, a missing file, a bad branch.
+
+**Is:** the ops repo's Actions access is not set to organisation-wide.
+
+Settings -> Actions -> General on `roster-ops`. `roster doctor` checks this explicitly, and the
+portal's setup screen links straight to the page.
+
+---
+
+## A run was "cancelled" and nobody cancelled it
+
+**Is:** almost always the `timeout_minutes` ceiling. GitHub reports a job killed by
+`timeout-minutes` as `cancelled`, which reads as though somebody pressed a button.
+
+Tell them apart by duration. Several cancelled runs all stopping at the same minute is a
+ceiling, not a coincidence. `roster doctor` does this for you and names the number:
+
+```
+✗ cto-daily.yaml: 5 of the last 10 ran to a 60m ceiling and were killed
+```
+
+Raise `timeout_minutes` in the staff member's `staff.yaml`, then `roster upgrade --apply`.
+Note that raising it does not rewrite history: doctor reads the ceiling those runs actually hit,
+so old timeouts keep being reported as timeouts.
+
+---
+
+## Every mention run says "skipped"
+
+**Is:** correct. The job-level condition gates out every comment that is not a mention, and a
+gated run still appears in the list with conclusion `skipped`. Most of a mention workflow's
+history is skipped runs.
+
+`roster doctor` ignores them. A workflow whose runs are *all* skipped is reported differently,
+because nothing has exercised the credentials.
+
+---
+
+## The App exists, the API says so, and runs still fail
+
+**This is the one that costs the most time.**
+
+`GET /apps/<slug>` reports what an App **declares**. It says nothing about whether that App has
+been **installed** on the repository in question, or which repositories the installation was
+granted. The two are reported separately and they disagree exactly when you care.
+
+Do not verify an installation by reading the API. The only proof of the whole chain is a run
+that finished. `roster doctor` reads recent runs for this reason and calls a workflow that has
+never run **unproven** rather than fine.
+
+Fix: open the App's installation settings and check the repository list includes every tracker
+the staff member writes to, not just its own. `roster app` prints that list.
+
+---
+
+## An agent cannot push a workflow change
+
+**Is:** a GitHub restriction, not a misconfiguration. **App tokens cannot push any change under
+`.github/workflows/` in any repository.**
+
+This is why agents can never update their own workflows and why `roster upgrade` writes into
+your working tree and asks you to push. It is deliberate: an agent editing the workflow that
+constrains it is not a thing anybody wants.
+
+---
+
+## A fix I applied to the tenant disappeared
+
+**Is:** you edited a framework-owned file. `compose.mjs`, `agents.mjs`, `runner-plan.mjs` and
+`session.yaml` are generated. The next `roster upgrade` reconciles them against the template.
+
+This happened here: a fix went into `roster-ops/.github/workflows/session.yaml` instead of
+`templates/ops/...`, and nothing noticed because the framework had not touched that file *yet*.
+
+`roster upgrade` now reports an edit to a framework-owned file whether or not anything has
+collided, and `roster upgrade --check` fails on it. Move the change upstream.
+
+---
+
+## A new staff member's prompt will not compose
+
+```
+unknown or empty placeholder: {{staff.product.repo}}
+```
+
+**Is:** the prompt refers to something their manifest does not have. `product` comes from the
+first entry in `works_in`, and a staff member who contributes to no other repository has none.
+
+The shipped prompts guard these. A prompt fragment you have written yourself needs
+`{{#if staff.product}}` around anything that assumes one. Conditionals do not nest.
+
+Similarly `{{staff.status_issue}}` is empty until `roster hire --apply` has opened the pinned
+issue.
+
+---
+
+## A mention gets no reaction
+
+The eyes reaction is posted by `session.yaml` before any checkout, so it should land in
+seconds. If it does not:
+
+- The reaction is `continue-on-error`. A missing reaction never costs the answer, so check
+  whether the run itself started at all.
+- It is scoped to `kind == 'mention'`. A pr-mention is acknowledged by the forwarder in the
+  public repo instead, so that it gets one reaction rather than two.
+- On the `issues` route (a mention typed into a new issue body) the eyes go on the issue, not
+  on a comment, because that payload has no comment.
+
+---
+
+## The portal opened on a setup screen and I already have an org
+
+**Looks like:** roster forgot your organisation.
+
+**Is:** you started it somewhere else. The portal walks up from where it was run looking for a
+directory containing `org.yaml`; from an unrelated folder it finds nothing, which is a setup, not
+an error.
+
+`cd` to your workspace, or pass `--ops <dir>`. If the workspace is on another machine or was never
+cloned here, the setup screen's own answer is right: pick the org, and it will say it already runs
+roster and offer to check it out.
+
+---
+
+## My AI wrote the charter and the portal will not save it
+
+**Looks like:** the paste box rejecting good work.
+
+**Is:** almost always one of four things, and the page says which, with a line to send back:
+
+- the reply had no `<<<ROSTER FILE …>>>` block, because the model answered in prose
+- it wrote a path the brief did not ask for, which is never offered as a save
+- it handed the template back, which some models do after a long prompt
+- it is a few lines long
+
+The file itself is never the problem: text outside the block is ignored and one wrapping fence is
+stripped, so chat and ```` ```markdown ```` are both fine.
+
+---
+
+## The App was created and the portal tab never noticed
+
+**Looks like:** the page stuck on "Confirm it in the tab that just opened".
+
+**Is:** GitHub redirects the tab *it* opened, not the one you clicked from, so the original polls
+for the result. It gives up after five minutes and tells you to reload.
+
+**The App was probably created.** Check the org's App settings before trying again; a second
+attempt fails on the name, which is the safe failure.
+
+---
+
+## The portal shows stale data
+
+It reads the repositories on disk. `/api/sync` fetches and fast-forwards on every refresh, and
+refuses to pull a repository that is dirty or has diverged, saying so in a banner. If a run
+landed on GitHub thirty seconds ago and the checkout is behind, that is what you are seeing.
+
+---
+
+## `roster upgrade` says a file has no base
+
+A tenant created before the merge base was recorded has nothing to merge against. Reconstruct
+one from the framework's history:
+
+```bash
+roster upgrade --baseline <git-ref>
+```
+
+Use the framework commit the tenant was seeded from. Check it afterwards: files that match the
+reconstruction byte for byte confirm you picked the right one.

package/docs/upgrading.md

@@ -0,0 +1,83 @@
+---
+title: "Upgrading"
+description: "How framework changes reach a tenant without eating your edits."
+sidebar_order: 9
+---
+
+# Upgrading
+
+The framework writes templates out. A tenant runs its own copies. So the two drift, and
+`roster upgrade` is what reconciles them without eating your edits.
+
+```bash
+roster upgrade                 # what would change
+roster upgrade --apply         # do it
+roster upgrade --check         # exit non-zero if anything is pending (for CI)
+```
+
+## How it decides
+
+A generated file has three versions: what the framework shipped when this tenant was seeded,
+what it ships now, and what you have today. Upgrading is a three-way merge between them, done
+by `git merge-file`. A tenant that has rewritten half of `org/voice.md` still gets the rest.
+
+The base lives in `<ops>/.roster/seed/` and is committed. Without it an upgrade can only be a
+copy, which would take your edits with it.
+
+## Ownership decides what an edit means
+
+**In the ops repo:**
+
+| | |
+|---|---|
+| `org/`, `prompts/` | yours. Local edits are expected and get a real merge. |
+| everything else | the framework's. An edit is reported whether or not anything has collided. |
+
+That last rule is deliberate. A fix applied to a framework-owned file in the tenant is not safe
+just because nothing broke; it survives only until the framework next touches that file. "Not
+broken yet" is the state a lost fix sits in, so it is reported then, not later.
+
+**In a brain repo, only the caller workflows are upgraded.** The charter, the memory index, the
+decisions log and the manifest belong to the staff member from the moment they are created. A
+working agent rewrites them beyond recognition, and merging a template into that would be
+vandalism. They are added when new and never rewritten.
+
+## Callers are regenerated, not merged
+
+A caller is derived entirely from the manifest and the template, so there is no third version
+to reconcile. What looks like a local edit is either a template change that has not arrived, or
+something that should have been a manifest change.
+
+The diff is printed either way, so nothing goes quietly.
+
+If you want a caller to differ, change the thing it is generated from. Timeouts, schedule,
+model and identities all live in `staff.yaml`.
+
+## Conflicts
+
+A conflict is never written into a live file. Agents read `org/voice.md` at every boot, and
+conflict markers in it would land in every composed prompt.
+
+Instead the merged result with markers goes to `<file>.roster-merge`, the live file is
+untouched, and the recorded base does **not** advance for that file. That last part matters:
+advancing it would throw away the only thing that can merge it next time.
+
+Resolve by hand, then re-run.
+
+## A tenant with no recorded base
+
+Tenants created before this existed have nothing to merge against. Reconstruct it from the
+framework's own history:
+
+```bash
+roster upgrade --baseline <git-ref>
+```
+
+Pick the framework commit the tenant was seeded from. You can tell you picked the right one:
+most files will match it byte for byte, and the ones that do not will be the ones you know you
+edited.
+
+## After applying
+
+`roster upgrade --apply` writes into your working trees. It does not commit or push, and it
+cannot: **App tokens cannot push a change under `.github/workflows/`**. Review, commit, push.

package/docs/writing-a-charter.md

@@ -0,0 +1,83 @@
+---
+title: "Writing a charter"
+description: "The one file nothing can generate for you, and the shape that has worked."
+sidebar_order: 5
+---
+
+# Writing a charter
+
+The charter is the personality. It decides what a staff member does when nobody is watching,
+what it refuses, and what it escalates.
+
+roster will not write it for you. That is not a missing feature. A generated charter produces a
+generic agent, and a generic agent produces work that is competent-looking and about nothing in
+particular, which takes longer to notice than no work at all.
+
+## Write it with your own AI
+
+```bash
+roster brief charter <handle>
+```
+
+That prints a self-contained brief. Paste it into whatever agent you use, or pipe it:
+`roster brief charter cto | pbcopy`. In Claude Code, `cd <staff-dir> && claude` then
+`/charter` runs the same text, because `roster hire` generates the slash command from it.
+
+**Or do the whole round trip in the portal.** *Write the charter* on that staff member's card
+copies the same brief with every file it refers to already inside it, including the peers'
+charters, so a chat window with no filesystem can do it. Paste the reply back and you get a diff
+and a save. See [the portal](portal.md).
+
+The brief tells the agent to read `org/business.md`, the shared operating
+layer, and every peer's charter, then interviews you and drafts from your answers. It also tells
+you what it cut and why.
+
+There is nothing agent-specific in it. Claude Code gets a slash command because it is the
+reference runner and the shape happens to fit; everything else gets the same words from
+`roster brief`.
+
+## What goes in it, and what does not
+
+**Only the difference.** The shared half already exists in `org/`: how anyone here operates, how
+we write, the guardrails everyone is bound by. All of it is composed into the prompt above the
+charter. Restating any of it wastes context on every run of every day and creates two places to
+change one rule.
+
+If a sentence would be true of every staff member you will ever hire, it belongs in `org/`.
+
+## The shape that has worked
+
+**Who I am.** One paragraph. What this role is for, in this business specifically.
+
+**The mission.** The single thing this staff member optimises. If a decision does not serve it,
+it is somebody else's decision.
+
+**How I work, that others here do not.** The habits particular to this role.
+
+**Decision rights.** What it decides alone, what it proposes and waits on, what it never
+touches. Be specific. A vague boundary is one that gets crossed at 07:00 with nobody awake.
+
+**Guardrails on top of the org's.** Only the additions.
+
+**Where the rest of it lives.** Point at `memory/INDEX.md`, `log/decisions.md`, the pinned
+status issue, and the surfaces the manifest declares.
+
+## Things worth being concrete about
+
+- **Escalation.** Name the label and the mechanism, not the sentiment. "Open an issue labelled
+  `decision`, assigned to `@you`" beats "check with the founder".
+- **What it must not do.** Money, legal, anything touching a real person's data. Say it here
+  even if `org/guardrails.md` covers it, if this role gets closer to the line than others.
+- **What good output looks like for this role.** A CTO's and a CMO's differ, and the shared
+  voice file cannot know that.
+
+## Keep it agreeing with the manifest
+
+`roster lint` fails if the charter and `staff.yaml` disagree. The manifest is the
+machine-readable half of the same document: handle, schedule, peers, surfaces, identities. If
+the charter says it reviews pull requests on the product repo, `works_in` had better include it.
+
+## It is not finished
+
+The charter is the file most worth revisiting. When a run does something you did not want, the
+question is usually not "what went wrong in that run" but "what does the charter not say".

package/package.json

@@ -0,0 +1,60 @@
+{
+  "name": "@nanocollective/roster",
+  "version": "0.1.0-alpha.1",
+  "description": "An agent-run org, powered by GitHub. Scaffold AI staff members whose brain is a repo.",
+  "type": "module",
+  "bin": {
+    "roster": "./dist/cli.js"
+  },
+  "files": [
+    "dist",
+    "templates",
+    "docs",
+    "README.md",
+    "LICENSE"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "scripts": {
+    "build": "tsup src/cli.ts --format esm --target node20 --clean",
+    "dev": "tsx src/cli.ts",
+    "test": "tsx --test test/*.test.ts",
+    "test:all": "pnpm test:format && pnpm test:lint && pnpm test:types && pnpm test:knip && pnpm test",
+    "test:ava:coverage": "c8 --reporter=text --reporter=json-summary tsx --test test/*.test.ts",
+    "test:format": "biome check --no-errors-on-unmatched .",
+    "test:lint": "biome lint .",
+    "test:lint:fix": "biome check --write .",
+    "test:types": "tsc --noEmit",
+    "test:knip": "knip",
+    "test:audit": "pnpm audit --audit-level=high",
+    "test:security": "semgrep scan --config auto --error",
+    "typecheck": "tsc --noEmit",
+    "format": "biome check --write .",
+    "prepublishOnly": "pnpm test:all && pnpm build"
+  },
+  "devDependencies": {
+    "@biomejs/biome": "^2.5.12",
+    "@types/node": "^22.10.2",
+    "c8": "^12.0.0",
+    "knip": "^6.34.0",
+    "tsup": "^8.3.5",
+    "tsx": "^4.19.2",
+    "typescript": "^5.7.2"
+  },
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Nano-Collective/roster.git"
+  },
+  "homepage": "https://github.com/Nano-Collective/roster#readme",
+  "bugs": {
+    "url": "https://github.com/Nano-Collective/roster/issues"
+  },
+  "author": "Nano Collective",
+  "packageManager": "pnpm@11.0.9",
+  "publishConfig": {
+    "access": "public",
+    "tag": "latest"
+  }
+}