Report per-agent and per-engine token usage from a sealed run

.github/workflows/deploy-website.yml

@@ -19,6 +19,8 @@ concurrency:
 
 jobs:
   build:
+    name: build simfile.org
+    timeout-minutes: 30
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
@@ -47,6 +49,8 @@ jobs:
           path: website/dist
 
   deploy:
+    name: deploy simfile.org
+    timeout-minutes: 15
     needs: build
     runs-on: ubuntu-latest
     environment:

.github/workflows/publish.yml

@@ -20,6 +20,8 @@ concurrency:
 
 jobs:
   publish:
+    name: publish simfile to npm
+    timeout-minutes: 20
     runs-on: ubuntu-latest
     env:
       RELEASE_TAG: ${{ github.event_name == 'workflow_dispatch' && inputs.tag || github.ref_name }}

.github/workflows/test.yml

@@ -6,7 +6,9 @@ on:
     branches: [main]
 
 jobs:
-  check:
+  typecheck-and-audit:
+    name: typecheck + dependency audit
+    timeout-minutes: 15
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
@@ -18,12 +20,14 @@ jobs:
       - run: npm audit --omit=dev --audit-level=high
       - run: npm run typecheck
 
-  test:
+  # Split by what the suite actually covers, not by arbitrary file shards.
+  # `src/dynamics` builds npm packages inside hermetic sandboxes: 16% of the
+  # tests but ~55% of the CPU, so it gets its own job. A red job then names the
+  # area that broke, which "test (3)" never could.
+  world-and-runtime:
+    name: world + runtime tests
+    timeout-minutes: 25
     runs-on: ubuntu-latest
-    strategy:
-      fail-fast: false
-      matrix:
-        shard: [1, 2, 3, 4]
     steps:
       - uses: actions/checkout@v4
       - uses: actions/setup-node@v4
@@ -32,11 +36,24 @@ jobs:
           cache: npm
       - run: npm ci
       - run: npm run build
-      # The GitHub-hosted runner has 2 cores, so `node --test`'s file-level
-      # parallelism can't spread the CPU-heavy dynamics-build suites — the full
-      # suite runs ~20 min there despite ~2 min on an 18-core dev box. Shard the
-      # files across parallel jobs so wall time is the slowest shard, not the sum.
-      - run: >-
+      - name: Run every suite except the dynamics sandbox builds
+        run: >-
           node scripts/run-tests.mjs
-          --test-shard=${{ matrix.shard }}/4
-          "src/**/*.test.ts" "web/src/**/*.test.ts"
+          $(find src web/src -name '*.test.ts' -not -path 'src/dynamics/*' | sort)
+
+  dynamics-sandbox-builds:
+    name: dynamics sandbox builds
+    timeout-minutes: 25
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+      - name: Build and load dynamics packages in hermetic sandboxes
+        run: >-
+          node scripts/run-tests.mjs
+          $(find src/dynamics -name '*.test.ts' | sort)

.gitignore

@@ -4,6 +4,8 @@ dist/
 coverage/
 !src/coverage/
 .artifacts/
+.simfile-dev/
+.simfile-composed/
 runs/*
 !runs/real-grok-composed/
 !runs/office-world-v0/

AGENTS.md

@@ -1,7 +1,8 @@
 # Simfile Working Guide
 
-This folder, inside the Spawnfile repository, is the reference implementation
-of the Simfile v0.1 world mechanics package.
+This standalone repository is the reference implementation of the Simfile
+v0.1 world mechanics package. Spawnfile may be installed as a separate tool or
+checked out anywhere; never infer a sibling repository or import its source.
 
 ## Repository Structure
 
@@ -28,9 +29,31 @@ of the Simfile v0.1 world mechanics package.
 - Keep CLI handlers thin; schema, planning, ledger, and runtime logic belong in modules.
 - Do not import Spawnfile internals. Consume explicit machine-readable artifacts.
 - Do not add Docker compilation, runtime auth, or deployment ownership here.
+- Source-development tool setup belongs under ignored `.simfile-dev/` state and
+  must require an explicit package coordinate or absolute checkout path.
 - `simfile run` may compose a linked Spawnfile lifecycle only through documented
   CLI operations and versioned receipts. Lifecycle composition never selects,
   wakes, invokes, polls, or waits for agent cognition.
 - Keep `src/run/` as the timer-free local deterministic writer. Generic composed
   lifecycle code belongs in its own implementation folder and must be reused by
   any future `simfile dev` watch/debug wrapper.
+
+## Branches and pull requests
+
+**Never commit to `main`.** Every change lands through a pull request, without
+exception — including one-line fixes, CI configuration, documentation, and
+version bumps. Work on a branch, push it, open the PR, and let CI run.
+
+Direct commits to `main` bypass the checks that catch what local runs do not.
+A zero-byte receipt store, a package that ships without its native binary, and
+a two-week-red pipeline all reached `main` in this ecosystem while every local
+gate was green — CI found them the first time it ran over the code.
+
+- Branch names describe the change: `feat/…`, `fix/…`, `ci/…`, `docs/…`.
+- Commit messages are conventional and single-line (`feat:`, `fix:`, `docs:`,
+  `ci:`, `chore:`, `refactor:`, `test:`).
+- Never add co-author lines, sign-offs, or AI attributions.
+- Commit as you go rather than in one batch at the end, so history shows how
+  the work progressed.
+- Merge with a merge commit rather than a squash when the individual commits
+  carry meaning; squashing collapses that history irreversibly.

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Noopolis
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.