The board: tasks and requests
Every piece of work on SHarness as one row, numbered so it can be referred to from any page, commit or conversation, and never renumbered. R is a request: it needs the editor (a decision, a key, a setting) and says what it blocks. T is a task: work a member has or anyone can pick up. One file per row under content/admin/board/; the Sherpa keeps the rows honest and scopes them into releases, the conductor builds this page from them, and anyone opens a row by adding a file (how). 14 request(s) wait on the editor and 16 task(s) are open, as of 26 Oct 2026.
Needs the editor
| # | Item | Owner | Status |
|---|---|---|---|
| R3 | Review the design pages against the source pack. Before they are used to brief the building agents. Especially: the claim labels (measured / designed / not yet measured), the renaming of sgit-* components to sharness.*, and the published observations of the Claude workspace on Evidence §7.opened 2026-10-24 | editor | needs review |
| R5 | Read the articles written in Dinis's voice and the build agent's own. A secure harness for agents is written in Dinis's voice from voice memo 01 and he has not read it yet; two phrases of the transcript were left out as unclear. What shipped on day one is the build agent's own. Added in v0.5.0: the market and competitive analysis, a survey on one day with secondary-source figures marked as such. Added in v0.5.2: Containment and Languages (decision 11). opened 2026-10-24 | editor | needs review |
| R6 | Review the research note, the experiments and the storyboards' cast. The research note lists ten findings and an order for E05 to E08; the cast (Ada, Pip, Rook, the Launcher) is proposed for Dinis to accept, change or replace; the article The first experiments is the build agent's own. opened 2026-10-24 | editor | needs review |
| R7 | Release the CLI's dev to main. The next release would carry sharness-ai as the only command and the experiments E01 to E04, E09 and E10; until then the experiments install from the repository and pip install sharness-ai installs a skeleton that prints its version. Getting users calls this the single change that matters most for users; nothing is announced before it. Dinis's decision, 26 Oct 2026: after one more pass over security and functionality, not before. Week 0 of the outreach plan waits on it.opened 2026-10-24 | editor | waiting |
| R11 | A go on the outreach plan, per channel, and who posts. The outreach plan: your accounts for LinkedIn, Hacker News and Reddit; the agent, disclosed, for issues, Discussions and pull requests to lists. Also whether the London chapter's organisers are a warm contact, and whether the newsroom's Journalist or the sherpa writes the release posts. Nothing is posted until then. The telemetry page's policy is yours to confirm or change too. Opened by sherpa@sharness. The editor, 26 Oct 2026: paused until the website is in a much better place; the first channel will most likely be LinkedIn. The mapping stands; nothing is posted. opened 2026-10-25 | editor | waiting |
| R12 | A comms vault and a contact file for conductor@sharness. So that the conductor can be written to the way every agent in the sgit.ai network is: a comms vault whose append lane is its inbox, its public keys and the lane's token published at /.well-known/sgit-agents.json and on an /agents/ page, following Agent Contact v0.1. Needs from the editor: the vault created (or a go to create it from a session that has the sgit CLI and an SG/Send access token), its key handed over sealed to the session's key as pki.sgit.ai describes, and sharness.ai added to the allow lists of the sites that should be able to write to it. Until then the repository is the channel: a board row or a To-conductor: note. Nothing secret is ever published; the vault ID and the public keys will be.opened 2026-10-25 | editor | open |
| R13 | Accept or change the conductor's role and the three hats it wears. The conductor's role and draft policy say what it owns and the rules it works by, and that for now it also carries the librarian, the ontologist and the project manager, each written as a paragraph that can be handed to an agent later. Also to confirm: the member folders written for the editor, cli@sharness and dev@sharness from what the site already said about each; each is a draft until its member or the editor accepts it. opened 2026-10-25 | editor | open |
| R15 | Set the repository and account settings on the security lock-down list (branch rulesets, 2FA, push protection, the PyPI publisher bound to an environment). The security review of 25 Oct 2026 (Reviews, register row SR-24) found main and dev of both repositories unprotected, one account administering both, and a push to the CLI's main publishing to PyPI. Nothing in a repository can change these; Hardening §3 is the checklist, with the weight of each item: two-factor for the organisation; branch rulesets on main and dev requiring a pull request and the tests, security and codeql checks, blocking force pushes and deletion; a tag ruleset for v*; secret scanning with push protection; Dependabot alerts; private vulnerability reporting; the Trusted Publisher on PyPI bound to a pypi environment with a required reviewer; Pages deploying only from Actions and only from dev and main. One decision inside it: the release workflow pushes a version-bump commit to main, which a ruleset blocks unless the Actions actor is on its bypass list; the alternative is to derive the version from the tag in the build job and never commit it from CI. The editor sets these and ticks them; the security agent confirms what the API shows afterwards.opened 2026-10-26 | editor | open |
| R16 | Decide the environment row for the policy (process.env), so a confined child stops inheriting every variable of the process that confined it. Register row SR-11: today sharness-ai run passes the whole environment of the applying process to the child, API keys and proxy credentials included, because v0 has no row for it; since 25 Oct 2026 run says so on stderr every time and policy check in its advice. Proposed for the next policy version: process.env taking "inherit", "clean" or a list of variable names to pass. A new optional key leaves every existing hash unchanged; a CLI without the key refuses the unknown key, which is the right failure. The designed end state removes most of the need (sharness.llm and sharness.kms hold the secrets), but the row is cheap and closes a Medium gap now. The editor decides the shape; the security agent implements it with a test and the hash fixtures.opened 2026-10-26 | editor | open |
| R17 | The go on the schedule cards: one scheduled task per member, from each card. Every agent member has a card on the schedule with its wakes (London time), its cron and its wake prompt word for word, all proposed. The editor's go per card creates the scheduled task on the account that runs that session (the steps are on the schedule page and on each member's page), and the member makes its card active in its next release. Proposed cadence: the conductor every two hours 07:20 to 21:20; cli@sharness 09:00; dev@sharness 09:30; pbp@sharness 10:10; the Sherpa 08:45 and 17:45; security 21:35. Nothing in the quiet hours. Also to decide: which account runs which session, since a card can be set up on any; the brief is schedules, cards and start pages.opened 2026-10-26 | editor | decision |
| R18 | The CLI repository's settings for visitors: Discussions on, the description and the topics. From the CLI ready for visitors: what the GitHub tools cannot set from a session. Discussions switched on; the repository description (one sentence: a policy the kernel enforces, for every process an AI agent starts; experiments stage) and the topics (landlock, sandbox, ai-agents, process-policy, security, python). The exact values come with the Sherpa's texts; nothing is posted anywhere before R7 and R11. opened 2026-10-26 | editor | open |
| R19 | Merge Dependabot's pull requests on the CLI (#2, #3), opened by the new dependabot.yml. From security@'s note of 26 October (CLI 7dcbe05): Dependabot opened pull requests #2 and #3 from the dependabot.yml it added (the actions bumps to checkout v7 and setup-python v7 also clear the Node 20 deprecation warning); tests and CodeQL pass on both. They are the editor's to merge, as the repository's rules are. Three Dependabot branches sit ahead of dev until then.opened 2026-10-26 | editor | decision |
| R20 | The split of the build agent into cli@sharness and website@sharness; the website agent's brief. Decided by the editor in the build agent's session on 26 October 2026: the build agent becomes cli@sharness (it renames itself on the site) and the site gets an agent of its own, website@sharness. The conductor wrote the website agent's folder as a draft, with a start prompt on its page, so a new session on any account can be onboarded with one line. Still needed from the editor: the session itself (attach the website repository with push access, name it sharness.ai | website@, paste the start prompt), and the brief in his words, which the agent publishes under content/admin/briefs/ as its first commit. The go on its card (09:15 London, proposed) is part of R17.opened 2026-10-26 | editor | open |
| R21 | Create the three language repositories, so the implementations can leave their staging branches. From R8's decision. The GitHub app this session runs under cannot create a repository in the organisation (POST /orgs/SHarness-AI/repos answered 403 on 26 Oct 2026), so the editor creates them: SHarness-AI__JS, SHarness-AI__Go and SHarness-AI__Rust, public, Apache 2.0 like the CLI, empty (no README, no licence, no .gitignore: the trees carry their own), with dev as the default branch once pushed. Suggested descriptions: SHarness in JavaScript, for Node and the browser: a reference implementation of Process Behaviour Policies against the standard on sharness.ai, checked by its test vectors in CI. Experiments stage; the same with Go: ... a static binary and Rust: ... the KMS and the bash client are its first targets. Then dev@sharness pushes each staging branch as that repository's dev (git push <repo> claude/js-reference:dev), and the Claude GitHub App needs the new repositories in its installation so a session can push to them. Until then the trees are the CLI repository's branches claude/js-reference, claude/go-reference and claude/rust-reference, and the registry says so.opened 2026-10-26 | editor | open |
Open tasks
| # | Item | Owner | Status |
|---|---|---|---|
| T1 | Run the process-tree proof of concept and publish its results on Evidence. Roadmap decision 6; experiment E06 on the experiments ladder. Follows the safety rules for testing inside a live agent session. opened 2026-10-24 | cli | open |
| T2 | Fix the known issues in the source pack in its next revision. A broken link and mixed component names; the published copy stays verbatim. See the list. opened 2026-10-24 | editor | open |
| T3 | Pages for the CLI's commands as they are built, each with a markdown twin. The CLI page is markdown and carries E01 to E04, E09 and E10; per-command pages when the components come. opened 2026-10-24 | cli | in progress |
| T5 | List the SHarness storyboards as a series on storyboards.sgit.ai. Its importer takes content/storyboards/ as it is.opened 2026-10-24 | sherpa | open |
| T6 | E05 to E08 in the research note's order, then the launcher above the agent. The process tree (E06), the edges as a script (E05), the KMS v0 (E08), the LLM gateway v0 (E07); then the launcher as a script above the agent on a laptop. The order and the reasons are in the research note. opened 2026-10-24 | cli | open |
| T8 | The CLI repository ready for visitors, before any post. Outreach §3.1: description, topics, README with the playground first, Discussions on with three seeded threads, four or five real good first issues, SECURITY.md and CONTRIBUTING.md. Needs write access to the CLI repository, which the sherpa's session does not have; the conductor's does (T13 carries AGENTS.md there), so the two can split it: the brief the CLI ready for visitors says how; SECURITY.md is done (security@, v0.5.20). 26 Oct 2026: the Sherpa's half is written under content/admin/briefs/cli-visitors/ (the description and topics, CONTRIBUTING.md, three Discussions threads, four good first issues), per the brief; the conductor commits them to the CLI and opens the threads and issues; security@ reviews CONTRIBUTING.md first.opened 2026-10-25 | sherpa | in progress |
| T9 | The sharness-hello skill submitted to Anthropic's plugin directory. And listed on the third-party Claude directories; the skill's own page here as the landing page. opened 2026-10-25 | sherpa | open |
| T10 | cli@sharness and dev@sharness enrol on pki.sgit.ai at their next sessions. pki-agent keygen, operator the root, submission, so their releases can be signed and the agents can seal to each other. Also dev@sharness, and the conductor (R12). Opened by sherpa@sharness.opened 2026-10-25 | cli | open |
| T11 | Import the articles into newsroom.sgit.ai and list the storyboards on storyboards.sgit.ai. The articles are in the newsroom's format already; the storyboards' listing is T5. The network is the first channel of the outreach plan. Opened by sherpa@sharness. opened 2026-10-25 | sherpa | open |
| T12 | The repository checklist from sgit.ai: a reality file, a corrections file and a review folder for both repositories. Every sgit repository says what each repository in the estate carries. SHarness has most of it: the brief published in full, one version per push, a gate, roles and a board (from v0.5.14), machine-readable twins, the licences. Missing on 25 Oct 2026: a reality file as such (What exists today plays the part on the site; the CLI has none), a corrections file (BRIEF-CORRECTIONS.md; the pack's known issues are listed on the source documents instead), the review/ folder the review brief asks for, and a participant disclosure page. One per release, smallest first. The brief: a reality file and a corrections file, for cli@sharness.opened 2026-10-25 | conductor | open |
| T14 | The row shape in policy.py, so that policy check derives the barrier kind per row. From the PBP on one page §4 and §5: a policy row is subject, resource, operation, predicate (where), held_by and a derived kind. sharness-ai policy check should compute, for every behaviour row, whether its preconditions hold (the capability rows close every other path to the resource; one edge to the keeper) and report the barrier kind: Boundary when they do, Expectation when they do not, never an error. The summary then counts rows held by the kernel, rows held by a keeper and rows unheld, beside hello's probes held. Opened by pbp@sharness, who writes the shape; cli@sharness or dev@sharness write the code. The first predicate to carry is append_only, because sharness.fs is its keeper in the design.opened 2026-10-25 | cli | open |
| T17 | Signed commit notes: an Agent-Sig trailer checked against the member's enrolled key. An Agent: line is a claim anyone with push can write. The brief: signed commit notes. After T10 (every member enrolled on pki.sgit.ai); the conductor wires tools/notes.py and the notes page to show signed, unsigned and failing.opened 2026-10-26 | security | open |
| T18 | The dotted naming rule on About and naming: sharness.<door>.<target>, the dot means "sits on" and "sends to". Decided by the editor in pbp's session on 26 Oct 2026 and written on the PBP on one page §6: a door is sharness.<resource> (fs, net, db, llm, bash, kms); a target is sharness.<door>.<target>, where the door sends (sharness.db.sqlite, sharness.net.http, sharness.net.git, sharness.fs.s3, sharness.llm.tools) and sits on its parent, which closes every other path; depth is open and a level earns a name only when it adds nouns its parent cannot see. The naming rules on About and naming say sharness.<role> with seven names; they should carry the tree, and the code tree with it (sharness_ai.db.sqlite; a distribution sharness-ai-db-sqlite if a target leaves the CLI). For the conductor as ontologist; the component pages that follow from it are build@sharness's.opened 2026-10-26 | conductor | open |
| T19 | sharness.db.sqlite, the first door that runs: the sqlite3 module, structured requests, a PBP of its own. From the PBP on one page §6, at the editor's direction of 26 Oct 2026 (databases are the use case that makes the behaviour rows real). A door for one SQLite file, standard library only (sqlite3, http.server, ssl): it receives structured requests (select, insert, update, delete with table, columns, a filter, values), never a query string, and answers against the rows of the calling subject's policy: tables and columns allowed, a row filter, value ranges, rows per operation, a total per interval. Its own PBP allows one file under files.write; the app's excludes it, so the app reaches rows only through the door (a Boundary for the app, by the rule in §4). Within the component size target. Run under sharness-ai run with its policy, and hello-style probes: a row outside the filter refused, a value outside the range refused, a second insert over the count refused. Measured means a date and the kernel. Follows T14 (the row shape); read the security register before touching run.py.opened 2026-10-26 | cli | open |
| T20 | A door's conformance suite runs against its twin: sharness.fs.s3's refusals against the AWS twin's S3, no account needed. From the PBP on one page §6, at the editor's direction of 26 Oct 2026: a twin is a target with the real thing's signature, named in the invocation layer of the policy, so the same door runs under two hashes, target: twin and target: live. The test vectors for a target are therefore written once and run first against its twin. The first pair: sharness.fs.s3 (not yet designed in detail) against the AWS twin, whose Python twin answers S3's REST-XML and STS with boto3 unchanged; the probes are the door's refusals (a bucket outside the allowlist, a write to a read-only prefix, an object over the size cap, a delete when the policy allows none) and one allowed round trip, each saying which layer refused. Connectedness is a separate measured fact, never implied by a passing suite. For dev@sharness (the standards and their test vectors), with the twins site's owner for the twin's side.opened 2026-10-26 | dev | open |
| T21 | Two releases pushed seconds apart leave dev stuck: the cancelled run never tags, and the next one is refused. Seen on 26 October 2026 at 01:32 UTC. dev@'s v0.5.33 was pushed at 01:31:56 while v0.5.32's run was deploying; website@'s v0.5.34 followed at 01:32:08. The workflow's concurrency: pages group keeps one run in progress and one pending, so GitHub cancelled the pending v0.5.33 run when v0.5.34's queued (cancel-in-progress: false protects only the running one). v0.5.33 was never tagged, and v0.5.34's tag-release job refused itself: "latest tag is v0.5.32, expected v0.5.33, got v0.5.34". Every later release would have been refused the same way, since tools/ship.py bumps from the newest of the tag and dev's version.txt. Unstuck by hand at 01:40: website@ re-ran v0.5.33's run (tagged and deployed), then v0.5.34's (tagged, live at 01:44). Nothing was lost; the live site served v0.5.32 for twelve minutes. The fix is in .github/workflows/deploy-pages.yml, so it goes to security@ for review and needs the editor's go before it lands. Proposed: the tag-release job tags every site vX.Y.Z: release commit in the pushed range that has no tag yet, oldest first, before the patch check, so a cancelled run's release is tagged by the next run; the check stays strict for the newest. Until then: a release whose run is refused this way is unstuck by re-running the cancelled run, then the refused one, in that order.opened 2026-10-26 | website | open |
Done and decided
| # | Item | Owner | Status |
|---|---|---|---|
| R1 | The one-paragraph statement of what SHarness is and who it is for. Supplied by the design pack's brief; the front page, llms.txt and the CLI README now carry it.opened 2026-10-24, closed 2026-10-24 · shipped in v0.1.0 | editor | done |
| R2 | Repository settings for the deploy. Pages served by GitHub Actions, custom domain sharness.ai over HTTPS, and the github-pages environment allowing deploys from dev. Confirmed by the first release, v0.1.0, which deployed from dev and serves at https://sharness.ai.opened 2026-10-24, closed 2026-10-24 · shipped in v0.1.1 | editor | done |
| R4 | Command name. sharness-ai, decided 24 Oct 2026. Applied on the CLI's dev branch (the sharness shorthand removed); ships with the next CLI release (R7).opened 2026-10-24, closed 2026-10-24 | editor | decided |
| R8 | Decide the languages for the reference implementations. Roadmap decision 11, extended 25 Oct 2026. The developer agent's map and proposed order are in One standard, many languages: JavaScript first (one npm package for Node and the browser), Go second (the complete implementation with no third-party code), Rust third (the KMS and the bash client), Java, .NET and C later on interest. Also to decide: the repository layout (SHarness-AI__JS, __Go, __Rust proposed) and where the standards' test vectors live (proposed: on this site, fetched by every implementation's CI). The names sharness-ai on npm and crates.io were unclaimed on 25 Oct 2026. Owner of the work once decided: dev@sharness. Decided 26 October 2026, by the editor in dev@sharness's session: the languages and the order as proposed; one repository per language, each with the same structure, so that a component or a CLI can ship in that language on its own; the first implementation of a component is written in the language that suits it, not ported from Python; the vectors live on the site. The brief: one repository per language. What follows: the policy v0 standard and its vectors (/code/standards/, shipped with this decision), the JavaScript and Go implementations passing them, and R21 for the repositories themselves.opened 2026-10-25, closed 2026-10-26 | editor | decided |
| R9 | Confirm sherpa@sharness on pki.sgit.ai. The agent made its key on 25 Oct 2026 (record sha256:ceec8ed17051a3ba, encryption key sha256:d45cb071877e6897), linked you as its operator and sealed its submission, its encrypted keyfile and the passphrase to the root. Compare the fingerprint with the one in the session, confirm it in your vault's Agents tab (a month suggested: the key is a lasting one), add the submission to the register, and store the keyfile and passphrase as the environment secrets PKI_AGENT_KEY and SG_SEND_PASSPHRASE of its future sessions. The agents and their keys. Opened by sherpa@sharness. Superseded, 26 Oct 2026, by the editor's decision: an agent's identity key is ephemeral by design. It represents this session at this moment; it is never stored outside it. When the session is lost, a new session makes a new key and is confirmed again. The vault keys are a separate thing and sit with the vault keeper (sealed, 26 Oct, 00:18 UTC). Nothing waits on this row.opened 2026-10-25 | editor | superseded |
| R10 | An SG/Send access token for sherpa@sharness. Sealed to sha256:d45cb071877e6897 with send. Given in session on 25 Oct 2026 (in the chat, not sealed; the agent suggests rotating it). Both vaults pushed and the lane configured at 23:40 UTC. Still open from R9: the two environment secrets for the agent's next sessions. Opened by sherpa@sharness.opened 2026-10-25, closed 2026-10-25 · shipped in v0.5.12 | editor | done |
| R14 | Name every session that is running, so each has a member folder and a branch on the status page. The status snapshot reads the repositories, not the sessions: it sees branches and commits, not who runs them. On 25 Oct 2026 it finds the dev branches, main, and two claude/* branches with no commits of their own; a third agent, sherpa@sharness, released v0.5.11 and v0.5.12 at 23:27 and 23:30 UTC and is on the agents and their keys. The editor said "a whole number of agents" are running here. The conductor knows of cli@sharness, dev@sharness and sherpa@sharness from the commits and the bylines. Each other session needs a line from the editor (its name, its brief, its branch) or a content/admin/members/<id>/ folder of its own, as AGENTS.md section 5 asks. Answered 26 October 2026: the editor sent a screenshot of his sessions. Seven on this project, each a Claude Code session named sharness.ai | <role>@: build@, conductor@, security@, sherpa@, dev@, pbp@, and the first-day session sharness | cli, which is a cli@sharness session, idle since 24 October. pbp@ added its own folder, pbp@sharness, in its first release (v0.5.17, 23:52 UTC), with a To-conductor: note, the way AGENTS.md asks; security@ had none and has pushed nothing yet, so the conductor wrote it a draft from the session's title and its last status line, for the member to correct in its first commit. Every session is on the members with its state; the convention for naming a session is in AGENTS.md section 5.opened 2026-10-25, closed 2026-10-26 | editor | decided |
| T4 | The memo's acceptance test as a runnable example. A hello world with Claude inside SHarness, showing no internet and no file-system writes. Done for one child process (E04, sharness-ai hello, measured 24 Oct 2026, Evidence §9); for the agent itself it waits on the launcher above the agent (T6).opened 2026-10-24, closed 2026-10-24 | cli | done for one process |
| T7 | Open the telemetry lane. The telemetry lane opened 25 Oct 2026, 23:40 UTC (tools/telemetry_postmaster.py configure); both vaults pushed; the first drain at 23:45 UTC found 4 events, 2 of them real readers, and wrote data/telemetry-report.json. Next: render the counts on Telemetry once there are enough.opened 2026-10-25, closed 2026-10-25 · shipped in v0.5.12 | sherpa | done |
| T13 | AGENTS.md in the CLI repository, pointing at the site's guidance and the board. The CLI's CLAUDE.md carries the project rules; a short AGENTS.md beside it says where the board, the members and the updates live and how to talk in the commits (Agent: and To-<id>: trailers), so a session that starts in the CLI finds the same guidance as one that starts on the site.opened 2026-10-25, closed 2026-10-26 · shipped in v0.5.15 | conductor | done |
| T15 | Schedules, cards and start pages: the system. Built in v0.5.21: a card per agent member (content/admin/members/<id>/card.json) with its start prompt and wake prompt word for word; WAKE.md; tools/schedule.py (wake, run, card); run records under content/admin/runs/; the pages schedule, runs, briefs and the start-here block on every member's page. The brief: schedules, cards and start pages. The go to create the tasks is R17.opened 2026-10-26, closed 2026-10-26 · shipped in v0.5.21 | conductor | done |
| T16 | A release script, tools/ship.py: fetch, bump to the latest tag plus one, build, gate, push, verify live. Three agents released within minutes of each other on 25 October and the conductor's releases collided three times, build@'s three times too; each cost a merge, a renumbered row and a re-run of everything by hand. The brief: the release script. The conductor builds it at its next wake; cli@sharness reviews, since tools/ is its ground. Built at the conductor's wake of 00:32 UTC on 26 October as tools/ship.py, and used for its own first release. It refuses main and anything key-shaped, merges dev, takes the newest of the latest tag and dev's version plus one, adds the row, runs every generator and the gate, commits with the trailers from RELEASE_TRAILER, pushes to dev and tries once more from the merge if dev moved, pushes the branch, and polls the live site for the version. cli@sharness to review.opened 2026-10-26, closed 2026-10-26 · shipped in v0.5.24 | conductor | done |