diff --git a/.github/workflows/cortex_check.yml b/.github/workflows/cortex_check.yml index 44cd29c..3d49597 100644 --- a/.github/workflows/cortex_check.yml +++ b/.github/workflows/cortex_check.yml @@ -1,8 +1,8 @@ name: Cortex Check -# Guards the run-and-ruling registry: every phase file parses and its state is +# Guards the run-and-ruling registry: every task file parses and its state is # legal, every ruling id is unique and every Supersedes: resolves, every -# project a phase names is in projects.yaml, the gates/witness invariants hold +# project a task names is in projects.yaml, the gates/witness invariants hold # (`scripts/cortex.py check`), then the script's own tests. No self-heal here: # a failing check is a real contradiction and only a human can resolve it. The # generated pages that DO self-heal (`dashboard.md`, `dashboard.html`) are @@ -13,7 +13,7 @@ on: push: branches: [main] paths: - - "phases/**" + - "tasks/**" - "rulings/**" - "batches/**" - "projects.yaml" @@ -25,7 +25,7 @@ on: - ".github/workflows/cortex_check.yml" pull_request: paths: - - "phases/**" + - "tasks/**" - "rulings/**" - "batches/**" - "projects.yaml" diff --git a/.github/workflows/dashboard_refresh.yml b/.github/workflows/dashboard_refresh.yml index 6e65cd5..340278a 100644 --- a/.github/workflows/dashboard_refresh.yml +++ b/.github/workflows/dashboard_refresh.yml @@ -2,9 +2,9 @@ name: Dashboard Refresh # Keeps the generated Cortex pages (`dashboard.md`, linked from the README, and # `dashboard.html`, the Pages index) in step with the registry they describe. -# The pages are rendered by PyAutoBrain's cortex conductor from `phases/`, +# The pages are rendered by PyAutoBrain's cortex conductor from `tasks/`, # `rulings/`, `batches/`, `projects.yaml` and `checkin.yaml`, so any push that -# files a phase, moves it, records a run, lands a ruling or stamps a check-in +# files a task, moves it, records a run, lands a ruling or stamps a check-in # makes them stale. # # Same shape as the Mind's dashboard_refresh.yml, and for the same reason: on @@ -30,7 +30,7 @@ on: push: branches: [main] paths: - - "phases/**" + - "tasks/**" - "rulings/**" - "batches/**" - "projects.yaml" @@ -39,7 +39,7 @@ on: - "dashboard.html" pull_request: paths: - - "phases/**" + - "tasks/**" - "rulings/**" - "batches/**" - "projects.yaml" diff --git a/.github/workflows/ledger_merge.yml b/.github/workflows/ledger_merge.yml index 8061320..0a50911 100644 --- a/.github/workflows/ledger_merge.yml +++ b/.github/workflows/ledger_merge.yml @@ -3,7 +3,7 @@ name: Cortex Ledger Merge # Lands PyAutoCortex's own ledger work without anyone having to ask for it. # # THE PROBLEM. A branch-scoped session — the phone, claude.ai/code, any -# `claude/**` flow — pushes a phase move, a ruling, a batch record to a feature +# `claude/**` flow — pushes a task move, a ruling, a batch record to a feature # branch and it stops there: nothing downstream looks at a `claude/**` push. # The Mind learned this first (mind_ledger_merge.yml); the Cortex is born with # the answer. @@ -15,7 +15,7 @@ name: Cortex Ledger Merge # pushed it ever comes back. # # WHAT IT WILL AND WILL NOT MERGE. Only a branch whose whole diff is *ledger*: -# `phases/`, `rulings/`, `batches/`, `checkin.yaml`. The line is drawn by +# `tasks/`, `rulings/`, `batches/`, `checkin.yaml`. The line is drawn by # scripts/ledger_merge.py — a script, so it is testable and a session can # predict the verdict — and it is DEFAULT DENY: anything under `scripts/`, # `tests/`, `.github/`, `policy/`, `docs/`, `projects.yaml`, the prose pages, @@ -153,7 +153,7 @@ jobs: echo "verdict=ledger" >> "$GITHUB_OUTPUT" fi - # Structural drift on the branch tip BLOCKS. A phase in a state its + # Structural drift on the branch tip BLOCKS. A task in a state its # header contradicts, a dangling Supersedes:, a run line that does not # parse — nothing heals that automatically, and merging it would put the # contradiction on main. Also the only check audit mode gets to report. @@ -206,11 +206,11 @@ jobs: fi # THE TRIAL-MERGE CHECK. The branch passed alone; does it pass # merged? This is where two branches that both assigned the same - # ruling id, or both moved the same phase, are caught. + # ruling id, or both moved the same task, are caught. if ! python3 scripts/cortex.py check; then git reset --hard origin/main echo "::error::'$BRANCH' merges cleanly but 'cortex.py check' fails on the merged tree — left for a human" - echo "**Blocked** — \`$BRANCH\` fails \`cortex.py check\` once merged with main (a ruling-id or phase-state race?); left for a human." >> "$GITHUB_STEP_SUMMARY" + echo "**Blocked** — \`$BRANCH\` fails \`cortex.py check\` once merged with main (a ruling-id or task-state race?); left for a human." >> "$GITHUB_STEP_SUMMARY" exit 1 fi if [ -n "$PR" ]; then diff --git a/.github/workflows/pages_dashboard.yml b/.github/workflows/pages_dashboard.yml index 45a5f24..6a05ef4 100644 --- a/.github/workflows/pages_dashboard.yml +++ b/.github/workflows/pages_dashboard.yml @@ -6,7 +6,7 @@ name: Pages Dashboard # Why a twin exists at all: GitHub's markdown rendering strips JavaScript, so # `dashboard.md` can never write to the clipboard — on the GitHub mobile app its # fenced blocks have no copy affordance at all, leaving long-press text -# selection as the only way to grab a phase's command. The HTML page carries a +# selection as the only way to grab a task's command. The HTML page carries a # real copy button instead: one tap and the command is on the clipboard, ready # to paste into a Claude Code chat. It is also where a review is done — the # board is read on a phone as often as on the laptop. @@ -15,7 +15,7 @@ name: Pages Dashboard # `dashboard.md` (one census, two pages) and kept fresh by the same self-heal in # `dashboard_refresh.yml`; this workflow only publishes it. # Only the uploaded files reach Pages — nothing else in the repo, and in -# particular not `phases/`, `rulings/` or `projects.yaml`, whose absolute laptop +# particular not `tasks/`, `rulings/` or `projects.yaml`, whose absolute laptop # paths are not for a public site. on: diff --git a/AGENTS.md b/AGENTS.md index 18402cb..3d14104 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -31,7 +31,7 @@ Generated from `PyAutoMind/repos.yaml` + `PyAutoBrain/ORGANISM.md`; edit there, **The Mind decides what to build, the Brain routes the work and executes nothing, the Cortex learns what is true.** The Cortex is a **run-and-ruling -registry**: `project → phase → runs → rulings`. It owns two pieces of state no +registry**: `project → task → runs → rulings`. It owns two pieces of state no other organ holds — the **science body map** (`projects.yaml`: every science project, where it lives on the laptop and on RAL, how it syncs, where its own commentary ledger is) and the **rulings ledger of record** (`rulings/`: every @@ -39,13 +39,21 @@ verdict a human has passed on a science run, append-only). It is **not a second PyAutoMind.** The Mind is PR-shaped all the way down — prompts, issues, branches, completion records, "delivered = a PR with a diff -and checks". The Cortex's unit is a **phase** of a **project**, which spawns -**runs** (SLURM job ids) and ends in a **ruling**. Development tasks a science -phase waits on stay in the Mind and are named here only as **gates** — GitHub -issue/PR refs in a phase's `Gates:` header, one grammar, one direction. The +and checks". The Cortex's unit is a **task** of a **project**, which spawns +**runs** (SLURM job ids) and ends in a **ruling**. Development work a science +task waits on stays in the Mind and is named here only as **gates** — GitHub +issue/PR refs in a task's `Gates:` header, one grammar, one direction. The Mind learns nothing about the Cortex beyond a render-time badge. -The schemas — phase files, the run-line grammar, rulings, batches, the +**Tasks, not phases** (2026-09-07). A project holds *unordered* tasks — ideas +the human runs in whatever order the results and the priorities dictate — so +there is no number and no sequence. A task's identity is its **slug**, unique +per project by the path itself, and every task carries a required `Summary:` +of at most ten words: the *question* it answers, which is the one line the +board shows. Mind **epics** are still numbered phases; that is development +work, and it really is sequential. + +The schemas — task files, the run-line grammar, rulings, batches, the restricted `projects.yaml` subset — and the `scripts/cortex.py` verbs are in [REFERENCE.md](REFERENCE.md). Every choice the birth epic did not fix is dated in [docs/schema_decisions.md](docs/schema_decisions.md); read decisions there, @@ -67,11 +75,13 @@ human's turn. Full rules in [rulings/AGENTS.md](rulings/AGENTS.md). code, not ledger**: `sync_cli` and `local_path` are paths a conductor will execute under, so a change to it is always a human's turn. `cortex.py` reads it with PyYAML and validates the fields (REFERENCE.md "projects.yaml"). -- **`phases//.md`** — one file per phase, with the Mind's light - header (`Key: value` lines, no YAML frontmatter) and a `## Runs` body in the - SLURM run-line grammar. `State:` is one of `planned | gated | ready | +- **`tasks//.md`** — one file per task, with the Mind's light + header (`Key: value` lines, no YAML frontmatter — `Project:`, `Summary:`, + `State:`, …) and a `## Runs` body in the SLURM run-line grammar. There is no + `Phase:` number: the slug is the identity, and `check` names `Phase:` as a + retired key. `State:` is one of `planned | gated | ready | submitted | running | pulled | awaiting-ruling | accepted | rerun | dropped`. - `legacy` and `legacy_wrong` are states of a **run**, never of a phase. + `legacy` and `legacy_wrong` are states of a **run**, never of a task. - **`rulings///R--.md`** — the ledger of record. - **`batches/`** — closed history. Three 2026-08/09 batch records and the human's verbatim reviews under `reviews/`, kept because 13 rulings cite them @@ -85,27 +95,27 @@ human's turn. Full rules in [rulings/AGENTS.md](rulings/AGENTS.md). - **`scripts/cortex.py`** — the one lifecycle script (stdlib only): - `check` — every structural rule, hermetic; `cortex check: OK` or `DRIFT` with one ` - …` line per finding, exit 1. - - `gates` — read-only and offline: every gated phase, its refs and their + - `gates` — read-only and offline: every gated task, its refs and their URLs. Nothing polls GitHub and nothing flips a state; a human reads the - listing, opens the refs and types `move ready`. - - `rule --body …` — assigns the next ruling id, writes - the ruling file(s), updates the phase's `Ruling:` and `State:`. The only + listing, opens the refs and types `move ready`. + - `rule --body …` — assigns the next ruling id, writes + the ruling file(s), updates the task's `Ruling:` and `State:`. The only door to `accepted`, `rerun`, `dropped` and `leave-to-finish`. - - `move …` — every other transition, per the table in + - `move …` — every other transition, per the table in REFERENCE.md; refuses the ruling edges. - - `new --phase …` — writes a phase file from the - template. + - `new --summary "<≤10 words>" …` — writes a task file + from the template; `--summary` is required and capped, as `check` is. - `retire --why ""` — the only verb that writes `projects.yaml`: the row's `status:` becomes `retired` and its - `note:` records `retired : `. The row, its phases and its - rulings all stay; it refuses while any phase of that project is + `note:` records `retired : `. The row, its tasks and its + rulings all stay; it refuses while any task of that project is outside `accepted | rerun | dropped | planned`. - **`dashboard.md` / `dashboard.html`** — GENERATED, never hand-edited: the board, rendered by the Brain's cortex conductor and self-healed on `main` (see "Driving the Cortex" below). They are ledger for the merge gate. - **`scripts/ledger_merge.py`** — the default-deny classifier behind `.github/workflows/ledger_merge.yml`: a `claude/**` push whose whole diff is - ledger (`phases/`, `rulings/`, `batches/`, `checkin.yaml`, the two generated + ledger (`tasks/`, `rulings/`, `batches/`, `checkin.yaml`, the two generated dashboards) lands on `main` by itself; anything else waits for a human — and that "anything else" includes an `AGENTS.md` or `TEMPLATE.md` *inside* a ledger dir, which is doctrine, not an entry. `python3 @@ -118,23 +128,26 @@ lives in the Brain's **cortex conductor** — `pyauto-brain cortex `, or `python3 PyAutoBrain/agents/conductors/cortex/_cortex.py --cortex ` with no Brain install. It is read-mostly: it renders, it plans and it scores. The only bytes it writes of its own are the two generated pages; -every change to a *phase* goes through `scripts/cortex.py`, which owns the +every change to a *task* goes through `scripts/cortex.py`, which owns the state table. | Verb | What it does | |------|--------------| -| `checkin [--dry-run \| --apply] [--push \| --no-push] [--project KEY] [--skip-pull]` | **the check-in** — the one door: pull every active project through its own `sync_cli`, score every live phase, move what came back, re-render the board, push the ledger where the rule allows, and summarise **by project**. `--dry-run` is the default and reaches nothing | +| `checkin [--dry-run \| --apply] [--push \| --no-push] [--project KEY] [--skip-pull]` | **the check-in** — the one door: pull every active project through its own `sync_cli`, score every live task, move what came back, re-render the board, push the ledger where the rule allows, and summarise **by project**. `--dry-run` is the default and reaches nothing | | `census [--json]` | what the Cortex is holding, by state — the one-screen answer | | `dashboard --check` \| `--apply` | render `dashboard.md` + `dashboard.html`; `--check` exits **1 on drift**, **2 on bad args**, anything else = the renderer could not run | -| `gates` | every gated phase, its refs and their URLs — read-only, offline | -| `collect [--phase REL] [--pull] [--refreshed ISO] [--apply]` | score what came back; with no `--phase` it scopes to **every** `submitted \| running` phase, and `--pull` runs the *project's own* sync CLI | +| `gates` | every gated task, its refs and their URLs — read-only, offline | +| `collect [--task REL] [--pull] [--refreshed ISO] [--apply]` | score what came back; with no `--task` it scopes to **every** `submitted \| running` task, and `--pull` runs the *project's own* sync CLI | **`--apply` here, `--write` there.** The conductor's verbs spell the writing flag `--apply` (the Brain's house spelling, as intake does); `scripts/cortex.py` spells it `--write`. -**Nothing here submits a job.** A human runs the project's own `sync_cli -submit` line and the `cortex.py move submitted --run ` follow-up. +**Nothing here submits a job by itself.** A submission is made only on the +human's ask — by the human, or by the agent in the session — with the project's +own `sync_cli submit` line, followed at once by `cortex.py move +submitted --run ` (ruled 2026-09-05; before that the human typed the +submit). `checkin` and `collect --pull` are the only legs that shell out, and only to the project's own CLI — the conductor adds no SSH of its own. Each project `checkin` pulls gets a `/.cortex/pull.json` manifest @@ -172,7 +185,7 @@ exception, and it is confined to `projects.yaml`: a project's `local_path` and `mirror` are absolute laptop paths **outside** the workspace (the Science folder under `/mnt/c/…`), because that is where the datasets, the `output/` trees and the pulled results live and the review happens at the laptop. The -exception is stated in the file's header and here, and nowhere else — a phase +exception is stated in the file's header and here, and nowhere else — a task file or a ruling points into a project through its `projects.yaml` row, never with a bare absolute path of its own. @@ -199,9 +212,12 @@ so nobody re-derives these: > prompts that they are human-driven and supervised with a judged verdict as the > deliverable — **no transport was ever going to make those unattended.** -Every Cortex phase therefore runs on the laptop. That was once written into -each phase file as `Lane: local-dev` — 32 of 32 said the same thing, so the -header was deleted on 2026-09-03 and the fact lives here instead. +Every Cortex task therefore runs on the laptop. That was once written into +each task file as `Lane: local-dev` — 32 of 32 said the same thing, so the +header was deleted on 2026-09-03 and the fact lives here instead. (The quote +above is the Mind's, verbatim: the "phases 4, 6a and 6b" it names are phases of +the `euclid-dr1-prep` **Mind epic**, which is development work and genuinely +sequential — not Cortex tasks.) ## Hard rules @@ -209,8 +225,8 @@ header was deleted on 2026-09-03 and the fact lives here instead. 2. **Pull before edit.** `git fetch && git status` first, every time. 3. **Never edit a ruling.** Supersede it. `ledger_merge.py` refuses to auto-merge a modified or deleted file under `rulings/`. -4. **Run `python3 scripts/cortex.py check` before you push** a phase, ruling - or batch change; `ledger_merge.yml` runs it on the trial-merge tree and a +4. **Run `python3 scripts/cortex.py check` before you push** a task, ruling + or batch change (it is what refuses a missing or over-long `Summary:`); `ledger_merge.yml` runs it on the trial-merge tree and a failing check leaves the branch for a human. 5. **No hand-written HTML.** `dashboard.html` is rendered by the cortex conductor; a hand edit is drift that `dashboard_refresh.yml` will overwrite diff --git a/README.md b/README.md index 2a3497c..bb35e4b 100644 --- a/README.md +++ b/README.md @@ -7,23 +7,23 @@ body map** (every science project, where it lives, how it syncs) and the **rulings of record** — every verdict a human has passed on a science run, append-only, superseded but never edited. -**The board** — every phase the Cortex is holding, on one page, with the next +**The board** — every task the Cortex is holding, on one page, with the next command a tap away: (markdown twin: [dashboard.md](dashboard.md)). Both pages are generated by the Brain's cortex conductor and refreshed on every push; never hand-edit them. ## How PyAutoCortex works -The unit is a **phase** of a **project**, which spawns **runs** (SLURM job ids) +The unit is a **task** of a **project**, which spawns **runs** (SLURM job ids) and ends in a **ruling**: -1. **Declare the phase.** A markdown file under `phases//` states the +1. **Declare the task.** A markdown file under `tasks//` states the question, the pre-registered witness, the wall budget and the GitHub issues it waits on (`Gates:`). It starts `planned` or `gated`. -2. **Run it.** When the gates clear the phase is `ready`; a submission makes +2. **Run it.** When the gates clear the task is `ready`; a submission makes it `submitted` and then `running`, with every job id recorded in the file's `## Runs` block in SLURM notation. -3. **Pull and review.** When the results are pulled to the laptop the phase +3. **Pull and review.** When the results are pulled to the laptop the task becomes `pulled` and then `awaiting-ruling` — it is waiting on the human's eyes, and on nothing else. 4. **Rule.** The human's verdict — `accept`, `rerun`, `drop` or @@ -34,25 +34,25 @@ In full those four steps are ten states — `planned`, `gated`, `ready`, `submitted`, `running`, `pulled`, `awaiting-ruling`, then `accepted`, `rerun` or `dropped` — of which only the last three are reachable, and only through `scripts/cortex.py rule` (`legacy` and `legacy_wrong` are states of a *run*, -never of a phase). Checking in is one command from the Brain's cortex +never of a task). Checking in is one command from the Brain's cortex conductor — **`pyauto-brain cortex checkin --apply`** (see `--dry-run` first) pulls every active project through its own sync CLI, scores every submitted or -running phase against its pre-registered witness, moves what came back to +running task against its pre-registered witness, moves what came back to `awaiting-ruling`, re-renders the board, pushes the ledger where it is allowed -to, and prints a summary **by project** with the next prompt for each phase. `batches/` is closed history: the three 2026-08/09 batch +to, and prints a summary **by project** with the next prompt for each task. `batches/` is closed history: the three 2026-08/09 batch records and the human's verbatim reviews stay readable because 13 rulings cite them, and nothing writes new ones. The Cortex is **not a second PyAutoMind**: development tasks stay in the Mind and are named here only as gates. Its one script, `scripts/cortex.py`, checks -the tree and moves phases between states; the ledger folders auto-merge from +the tree and moves tasks between states; the ledger folders auto-merge from any surface that can push. `scripts/cortex.py` needs Python 3.10+ and **PyYAML** (`python3 -m pip install pyyaml`), which is how it reads `projects.yaml`; the tests additionally need `pytest`. Nothing else. -The schemas — phase files, the run-line grammar, rulings, the `projects.yaml` +The schemas — task files, the run-line grammar, rulings, the `projects.yaml` fields — are in [REFERENCE.md](REFERENCE.md); how agents should operate this repo is in [AGENTS.md](AGENTS.md); every design choice the birth epic did not fix is dated in [docs/schema_decisions.md](docs/schema_decisions.md). diff --git a/REFERENCE.md b/REFERENCE.md index 68dadc7..8448a8e 100644 --- a/REFERENCE.md +++ b/REFERENCE.md @@ -7,16 +7,16 @@ resolve here, one link from [AGENTS.md](AGENTS.md). --- -## What a phase looks like +## What a task looks like -Here is a phase file — `phases/example/05_running_array.md` from the test +Here is a task file — `tasks/example/05_running_array.md` from the test fixture — of a project whose GPU array is most of the way through: ````markdown -# Example — phase 5: the nine-lens array +# Example — the nine-lens array Project: example -Phase: 5 +Summary: Does Delaunay reach the same theta_E basin on ten lenses State: running Gates: PyAutoArray#431 Witness: nine of ten array tasks write a sane checkpoint.hdf5 within 8:00 wall @@ -33,16 +33,16 @@ Does the Delaunay pipeline reach the same theta_E basin on all ten lenses? ## Witness -`output/phase_05/*/checkpoint.hdf5` present for nine lenses, `.err` clean. +`output/task_05/*/checkpoint.hdf5` present for nine lenses, `.err` clean. ## Where to look -- `/mnt/c/Users/Jammy/Science/example/output/phase_05/` +- `/mnt/c/Users/Jammy/Science/example/output/task_05/` ## Runs - 342091_[0-8,10]: done — gpu — submitted 2026-08-30 — wall 6:12 - pulled_to: /mnt/c/Users/Jammy/Science/example/output/phase_05 + pulled_to: /mnt/c/Users/Jammy/Science/example/output/task_05 - 342091_9: failed — gpu — submitted 2026-08-30 — wall 0:00 — OOM before the first step - 342102: running — gpu — submitted 2026-09-01 — wall 0:00 — task 9 resubmitted alone after: 342091_9 @@ -63,24 +63,28 @@ sections are fixed: `## Question`, `## Witness`, `## Where to look`, `## Runs`, **`## Where to look` is rendered, not just parsed.** Its `- ` bullets are the answer to *which folder do I open* — the dashboard's `## By project` view and -`pyauto-brain cortex checkin` print them verbatim under the phase, and +`pyauto-brain cortex checkin` print them verbatim under the task, and `collect` resolves the ones that are absolute paths inside the project's roots to the artefacts it scores. `new` seeds the section with the placeholder -`- (the output path, once there is one)`, which is honest on a `planned` phase -and a hole on any other, so **`check` requires a phase whose `State:` is past +`- (the output path, once there is one)`, which is honest on a `planned` task +and a hole on any other, so **`check` requires a task whose `State:` is past `planned` to carry at least one bullet that is not that placeholder**. A bullet is free text: a path, a project-row-relative location, a Mind prompt, a GitHub ref — whatever a human would open. -### Phase header keys +A task has **no number**. Its identity is its **slug** — the file name, unique +per project by the path itself — because a science project is a set of ideas +run in whatever order the results dictate, not a sequence (decision, 2026-09-07). + +### Task header keys | Key | Value | Notes | |---|---|---| | `Project:` | project key | must equal the directory name **and** a `projects.yaml` key | -| `Phase:` | integer | unique per project; revival of a dropped phase is a new number | +| `Summary:` | at most ten words | **required** — the QUESTION the task answers, not its method or its run ids; the board's one line per task. No project name, no number | | `State:` | `planned \| gated \| ready \| submitted \| running \| pulled \| awaiting-ruling \| accepted \| rerun \| dropped` | | | `Gates:` | comma-separated GitHub refs | `Repo#N` (owner `PyAutoLabs`) or an issue/PR URL; **no `owner/Repo#N`** form | -| `Reset:` | reason | written by `move ready --reason ""` when a `submitted \| running` phase goes back to `ready` | +| `Reset:` | reason | written by `move ready --reason ""` when a `submitted \| running` task goes back to `ready` | | `Witness:` | free text | **mandatory before `submitted`** — the pre-registered checkable claim | | `Budget:` | `H+:MM` | wall budget per run | | `Runs:` | comma-separated job **stems** | the index of the `## Runs` body; equal to the set of body stems | @@ -88,7 +92,7 @@ GitHub ref — whatever a human would open. | `Review-minutes:` | integer | a seed, not a measurement | | `Epic:` | slug | OPTIONAL join key to a **Mind** epic; the Cortex keeps no epics file of its own | | `Filed:` | `YYYY-MM-DD` | | -| `Migrated-from:` | source path or ledger anchor | the Mind prompt, review file or project-ledger entry this phase was transcribed from (phase 4 of the birth epic) | +| `Migrated-from:` | source path or ledger anchor | the Mind prompt, review file or project-ledger entry this task was transcribed from (phase 4 of the birth epic) | Gate refs are matched by `GATE_REF_RE`, copied verbatim from `PyAutoMind/scripts/lifecycle.py`: @@ -106,7 +110,7 @@ The lookbehind `(? ready` — a human read `gates`, opened the refs and judged them cleared. No flag, and nothing written but `State:` | -| ready | gated | not an edge: re-gating a `ready` phase is a judgement, so it is a hand edit of the header | +| gated | ready | `move ready` — a human read `gates`, opened the refs and judged them cleared. No flag, and nothing written but `State:` | +| ready | gated | not an edge: re-gating a `ready` task is a judgement, so it is a hand edit of the header | | ready | submitted | `Witness:` non-empty AND `--run ` supplied | -| ready | pulled | legacy-born phase: every run line is `legacy\|legacy_wrong` (`new --legacy-run` / `move pulled`); `Witness:` still mandatory; every `legacy` run gets a `pulled_to:` (`--pulled-to`, else its own `where:`); refused when no run is `legacy` (nothing to review — `rule drop`) | +| ready | pulled | legacy-born task: every run line is `legacy\|legacy_wrong` (`new --legacy-run` / `move pulled`); `Witness:` still mandatory; every `legacy` run gets a `pulled_to:` (`--pulled-to`, else its own `where:`); refused when no run is `legacy` (nothing to review — `rule drop`) | | submitted / running | same | `--run ` appends a wave, a chained job or a checkpoint resubmit (`resumes:`); state unchanged | | submitted | running | — | | submitted / running | ready | no run line in `submitted\|running` AND ≥1 `failed\|timeout\|void`; `--reason` required (→ writes `Reset:`) | | running | pulled | no run line live; or `--partial` (a partial array), which `check` expects closed by a `leave-to-finish` ruling; `--pulled-to ` writes `pulled_to:` on every `done` run lacking one, and the move is refused when no `done` run would carry one | -| pulled | awaiting-ruling | — (the phase joins the rolling board) | +| pulled | awaiting-ruling | — (the task joins the rolling board) | | awaiting-ruling | accepted / rerun / dropped | **`rule` only** | | running / pulled / awaiting-ruling | same | `rule leave-to-finish` (state unchanged) | | accepted | rerun / dropped | `rule --supersedes ` only (the REWIND case) | | rerun | ready | — (the witness may be re-registered; run history is kept) | | any non-terminal | dropped | `rule drop` only | -| dropped | — | terminal (revival = a new phase number) | +| dropped | — | terminal (revival = a new slug) | `accepted` is **not** terminal: a later ruling may supersede the acceptance (2026-08-31's REWIND superseded accepted gates). `dropped` is. @@ -157,9 +161,11 @@ Offline invariants `check` enforces on top of the table: - `State = gated` ⇒ `Gates:` non-empty (a gate that does not exist cannot clear). - A header key outside the table is drift (`Gate:` must not pass as a silent - typo for `Gates:`); the five body sections are present; `Phase:` and - `Review-minutes:` are integers, `Budget:` is `H+:MM` and `Filed:` is - `YYYY-MM-DD`. A key with an empty value is read as absent. + typo for `Gates:`); the five body sections are present; `Summary:` is + present, non-empty and at most ten words; `Review-minutes:` is an integer, + `Budget:` is `H+:MM` and `Filed:` is `YYYY-MM-DD`. A key with an empty value + is read as absent. `Phase:` is named as a **retired** key rather than passing + as a generic unknown one — the number went on 2026-09-07. --- @@ -178,7 +184,7 @@ PyAutoCortex/ ├── dashboard.md ← GENERATED board — cortex conductor (`dashboard --apply`); LEDGER ├── dashboard.html ← GENERATED board, the Pages index; LEDGER │ -├── phases//.md ← one file per phase (LEDGER) +├── tasks//.md ← one file per task (LEDGER) ├── rulings/AGENTS.md ← the append-only rule ├── rulings///R--.md ← the ledger of record (LEDGER, append-only) ├── batches/AGENTS.md ← "closed history: never modified, only added" @@ -191,7 +197,7 @@ PyAutoCortex/ ├── scripts/cortex.py ← check · gates · rule · move · new · retire (stdlib + PyYAML) ├── scripts/ledger_merge.py ← the default-deny ledger classifier (+ append-only on rulings/, batches/) ├── tests/test_cortex.py tests/test_ledger_merge.py -├── tests/fixtures/skeleton/ ← one project, one phase per state, five rulings — the witness +├── tests/fixtures/skeleton/ ← one project, one task per state, five rulings — the witness ├── tests/fixtures/empty/ ← an empty map passes `check` │ ├── .github/workflows/cortex_check.yml ← check + pytest on push/PR @@ -223,7 +229,7 @@ structured facts on **indented continuation lines**, never in the note. - `` ∈ `submitted | running | done | failed | timeout | void | legacy | legacy_wrong`. `void` = cancelled or never produced a step. `legacy` / `legacy_wrong` = quarantine (reusable / not) — **a run state, - never a phase state**. + never a task state**. - `` — the SLURM partition the job went to, a bare word (`^[a-z][a-z0-9_-]*$`, e.g. `gpu`). The project's `partition:` row says which it may use. @@ -259,15 +265,15 @@ RUN_CONT_RE = re.compile( - every non-blank line under `## Runs` matches `RUN_LINE_RE` or `RUN_CONT_RE`; a continuation line follows a run line; -- task sets on one stem are **disjoint within a phase** (job ids are unique - per phase, not globally — one array may feed two phases); -- the `Runs:` header equals the set of body stems (both empty when the phase +- task sets on one stem are **disjoint within a task** (job ids are unique + per task, not globally — one array may feed two tasks); +- the `Runs:` header equals the set of body stems (both empty when the task has no runs); - `State: pulled` ⇒ at least one `done | legacy` run carries `pulled_to:`; - a `legacy | legacy_wrong` run carries `where:`; - an `after:` / `resumes:` target is the identifier (the text before the colon — `342091`, `342091_9` or `342091_[0-8,10]`) of another run line of - the **same phase**; + the **same task**; - a `ruled:` value resolves to a ruling file. --- @@ -277,13 +283,14 @@ RUN_CONT_RE = re.compile( `rulings///R--.md`. The id is `R-YYYYMMDD-nn` — a two-digit per-day sequence, global across projects; `rule` assigns it; the filename equals the id and so does the title line (`# ` or -`# — `). +`# — `); `rule` generates +`# — `. ````markdown -# R-20260901-02 — re-accept phase 8 with the corrected evidence pointer +# R-20260901-02 — re-accept example 08_accepted with the corrected evidence pointer Project: example -Phase: phases/example/08_accepted.md +Task: tasks/example/08_accepted.md Runs: 342050 Ruling: accept Supersedes: R-20260901-01 @@ -304,8 +311,8 @@ The human's words, verbatim. | Key | Value | Notes | |---|---|---| | `Project:` | project key | | -| `Phase:` | one phase path | repo-relative, `phases//.md` | -| `Runs:` | comma-separated stems, or empty | ⊆ the phase's `Runs:` | +| `Task:` | one task path | repo-relative, `tasks//.md` | +| `Runs:` | comma-separated stems, or empty | ⊆ the task's `Runs:` | | `Ruling:` | `accept \| rerun \| drop \| leave-to-finish` | the verb | | `Supersedes:` | one ruling id | optional; see the chain rules | | `Batch:` | `-` | optional-**historical**; the 2026-08/09 rulings' join, nothing writes new ones | @@ -316,8 +323,8 @@ The human's words, verbatim. Body: `## Ruling` — the human's words verbatim; `## Evidence` — pointers. -**One ruling file per phase.** A multi-phase ruling (a REWIND) is N `rule` -invocations with the same body — one per phase. +**One ruling file per task.** A multi-task ruling (a REWIND) is N `rule` +invocations with the same body — one per task. **Chain rules** (`check`): @@ -325,19 +332,19 @@ invocations with the same body — one per phase. the file's `/` directory; the body has `## Ruling` and `## Evidence`; - `Supersedes:` resolves to an existing ruling, is not the ruling itself, is - lexically smaller (earlier), and names the same project **and** phase; + lexically smaller (earlier), and names the same project **and** task; - **at most one successor per ruling** — a chain, not a tree: supersede the head; -- the phase's `Ruling:` is a chain head (no ruling supersedes it) whose - `Phase:` is that phase; -- the head's verb matches the phase's state: `accept ⇒ accepted`, +- the task's `Ruling:` is a chain head (no ruling supersedes it) whose + `Task:` is that task; +- the head's verb matches the task's state: `accept ⇒ accepted`, `drop ⇒ dropped`, `rerun ⇒ rerun | ready | submitted | running | pulled | - awaiting-ruling` (the phase has moved on), `leave-to-finish ⇒ any + awaiting-ruling` (the task has moved on), `leave-to-finish ⇒ any non-terminal state`; -- the ruling's `Runs:` ⊆ the phase's runs; +- the ruling's `Runs:` ⊆ the task's runs; - `Batch:`, when present, names an existing `batches/.md`. -A phase may hold rulings that are not chained to each other — a +A task may hold rulings that are not chained to each other — a `leave-to-finish` followed by an `accept` is two chains of one. `Supersedes:` is for replacing a verdict, not for sequencing. @@ -396,11 +403,11 @@ listed here. A document PyYAML cannot read is reported as one problem. the one verb that writes this file: it flips the row's `status:` to `retired` and rewrites (or appends) its `note:` as `"retired : "`. The **row stays** — it is the only record of - where that project's data lives — and no phase or ruling is touched; + where that project's data lives — and no task or ruling is touched; `rulings/` is append-only and a change of status is not a rewrite of - history. It refuses while the project holds a phase in any state + history. It refuses while the project holds a task in any state outside `accepted | rerun | dropped | planned`, naming each one, so the - live questions are ruled or dropped first; `planned` phases are unasked + live questions are ruled or dropped first; `planned` tasks are unasked questions and may stay. The edit is exactly those two lines — every other byte of the file is preserved — and the result is re-parsed before it is kept, the original bytes restored if it does not read @@ -422,7 +429,7 @@ deny**: | Ledger — merged automatically | Code — always a human | |---|---| -| `phases/**`, `rulings/**`, `batches/**` | `scripts/`, `tests/`, `.github/`, `policy/`, `docs/` | +| `tasks/**`, `rulings/**`, `batches/**` | `scripts/`, `tests/`, `.github/`, `policy/`, `docs/` | | `checkin.yaml` | `projects.yaml`, `README.md`, `AGENTS.md`, `REFERENCE.md`, … | | `dashboard.md`, `dashboard.html` (generated) | **`AGENTS.md` / `TEMPLATE.md` inside a ledger dir** | | | anything unclassified — a new root file, a new top-level folder | @@ -438,7 +445,7 @@ behaviour. Auto-merging a rewrite of `rulings/AGENTS.md` would let a branch edit the rule that governs its own merge. Pulling the other way, the two **generated** board pages are ledger: a branch -that moves a phase re-renders them in the same push, and +that moves a task re-renders them in the same push, and `dashboard_refresh.yml`'s self-heal commit has to land without a human. And a fourth Cortex rule on *kind* rather than path: `ledger_merge.py` @@ -467,27 +474,27 @@ Stdlib only; `main(argv)`; no import-time side effects; every verb takes `--root ` (default: the repo root the script lives in). Every leg of `check` takes `root: Path`, so tests run it against a `tmp_path` copy. -- **`check`** — every rule in this file: phase headers and states, the witness +- **`check`** — every rule in this file: task headers and states, the witness invariant, `## Where to look` naming somewhere past `planned`, run lines, ruling ids and chains, the verb↔state agreement, every project named by a - phase path is a `projects.yaml` key, and `projects.yaml`'s own fields. Hermetic (no network, no git). Output in `lifecycle.py`'s shape — + task path is a `projects.yaml` key, and `projects.yaml`'s own fields. Hermetic (no network, no git). Output in `lifecycle.py`'s shape — `cortex check: OK` or `cortex check: DRIFT` followed by one ` - …` line per finding; exit 1 on drift. -- **`gates`** — read-only and offline: every `gated` phase, its refs and the +- **`gates`** — read-only and offline: every `gated` task, its refs and the URL each ref resolves to (`GATE_REF_RE` → `gate_url`). Nothing polls GitHub and nothing flips a state. Grading was retired on 2026-09-03 — in its whole life it saw 2 gated refs and flipped 0, while schema decision 54 routes sequencing through prose `Ready when:` lines. A human reads the listing, - opens the refs and types `move ready`. -- **`rule --body [--supersedes ] [--batch ] + opens the refs and types `move ready`. +- **`rule --body [--supersedes ] [--batch ] [--minutes n] [--follow-up ]...`** — assigns the next id for today, - writes the ruling file, updates the phase's `Ruling:` and `State:` per the - table (and appends ` — ` to the phase's - `## Ruling`); the ruling's `Runs:` is the phase's, its `## Evidence` is the - phase's `## Where to look`; refuses to touch an existing ruling; refuses a - verb the table does not allow from the phase's state; validates everything + writes the ruling file, updates the task's `Ruling:` and `State:` per the + table (and appends ` — ` to the task's + `## Ruling`); the ruling's `Runs:` is the task's, its `## Evidence` is the + task's `## Where to look`; refuses to touch an existing ruling; refuses a + verb the table does not allow from the task's state; validates everything before writing anything. -- **`move [--run ] [--reason ..] +- **`move [--run ] [--reason ..] [--partial] [--pulled-to ] [--partition ..] [--after ] [--resumes ] [--note ..]`** — the table; refuses every ruling edge with a message naming `rule`. `--run` on `submitted`/`running` appends a @@ -497,23 +504,24 @@ Stdlib only; `main(argv)`; no import-time side effects; every verb takes partition is the project's `partition:` row unless that is `both`, when `--partition` is required. Every edit is an in-place header edit or an appended run line; every other byte of the file is preserved. -- **`new --phase [--gates ..] [--epic ..] +- **`new --summary "<≤10 words>" [--gates ..] [--epic ..] [--legacy-run ]... [--legacy-wrong ]... [--where ] [--partition ..] [--witness ..] [--budget ..] [--minutes n] [--title ..]`** - — writes `phases//.md` from the template in `planned` (or + — writes `tasks//.md` from the template in `planned` (or `ready` when `--legacy-run` / `--legacy-wrong` is given and every run is legacy); each legacy run line is written with today's date, `wall 0:00` and the note `pre-Cortex run, migrated` — the human corrects the date and wall by hand — and `--where` (required) as its `where:`; a legacy-born - phase refuses `--gates`. Refuses a duplicate phase number, an existing - file or an unknown project. + task refuses `--gates`. `--summary` is required and held to the same ten + words `check` holds it to. Refuses an existing file (the slug is the + identity — there is nothing else to collide on) or an unknown project. - **`retire --why ""`** — the only verb that writes `projects.yaml`: `status: retired` plus a `note:` reading `"retired : "`, two lines edited in place and every other byte preserved. Refuses an unknown key, an already-retired row, and any - project still holding a phase outside `accepted | rerun | dropped | - planned` (the message names each ` — `). The row, its - phases and its rulings all stay; see `projects.yaml` above. + project still holding a task outside `accepted | rerun | dropped | + planned` (the message names each ` — `). The row, its + tasks and its rulings all stay; see `projects.yaml` above. --- @@ -531,11 +539,11 @@ pyauto-brain cortex checkin --apply --skip-pull # re-score what is already her ``` It sweeps every `status: active` row of `projects.yaml`, plus any project that -owns a phase in `submitted | running`, and runs **that project's own** +owns a task in `submitted | running`, and runs **that project's own** `/ pull` — the verb all seven implement. Nothing else reaches a cluster; the conductor adds no SSH. A pull that exits non-zero is recorded against its project and the sweep continues. Then it scores every live -phase (the six legs below), moves `running → pulled → awaiting-ruling`, +task (the six legs below), moves `running → pulled → awaiting-ruling`, re-renders `dashboard.md` + `dashboard.html`, and prints a summary keyed **by project** — the last thing on screen, so a chat sees it first. @@ -566,13 +574,13 @@ carrying pull results and six-leg health). One builder, three renderings — a prompt added to a state appears in all of them. Per project: the three folders it lives in (`local_path`, `mirror` when it has -one, `ral_root`), what came of its pull, its phase counts by state, then every -phase that is still **open** — awaiting a ruling, still out there, ready to +one, `ral_root`), what came of its pull, its task counts by state, then every +task that is still **open** — awaiting a ruling, still out there, ready to submit, gated, planned — each with its state and health, its `## Where to look` bullets verbatim, and a copy chip per prompt its state carries. `accepted`, -`rerun` and `dropped` phases are history and appear only in the counts. A +`rerun` and `dropped` tasks are history and appear only in the counts. A project gets a block when its `projects.yaml` row is `status: active`, or when -it still holds an open phase; every other project folds into one line. +it still holds an open task; every other project folds into one line. On the board `## By project` is the **first** section, above the state lists: those are cross-project, so every row has to be read to find out whose it is, @@ -582,31 +590,31 @@ strip itself is unchanged (the Brain board reads it). ### The five starting prompts -Every phase row hands the reader a command rather than a decision. Which -prompts a phase carries is its **state**, and nothing else: +Every task row hands the reader a command rather than a decision. Which +prompts a task carries is its **state**, and nothing else: | Prompt | States | What it says | |---|---|---| -| rule on it | `pulled`, `awaiting-ruling` | read the witness and the pulled evidence, draft the ruling body, `rule --body ` | -| the results are good — accept and open phase N+1 | `pulled`, `awaiting-ruling` | `rule accept --body `, then open the next phase (below) | -| run it again | `pulled`, `awaiting-ruling`, `running` | `rule rerun --body `, `move ready`, the project's own submit, `move submitted --run ` | +| rule on it | `pulled`, `awaiting-ruling` | read the witness and the pulled evidence, draft the ruling body, `rule --body ` | +| the results are good — accept and open the next task | `pulled`, `awaiting-ruling` | `rule accept --body `, then open the next task (below) | +| run it again | `pulled`, `awaiting-ruling`, `running` | `rule rerun --body `, `move ready`, the project's own submit, `move submitted --run ` | | where the jobs stand | `submitted`, `running` | the project's own ` jobs` | -| submit it | `ready` | the phase, the project's own submit verb, `move submitted --run ` | +| submit it | `ready` | the task, the project's own submit verb, `move submitted --run ` | -(`gated` and `planned` phases carry the one-line `gates` / `move … ready` +(`gated` and `planned` tasks carry the one-line `gates` / `move … ready` command they always had.) -**Accept and open phase N+1** is two commands in one prompt because they are -one decision: an accept that opens nothing leaves the programme where it was. -Its second half prefills from the tree — when the project already holds a -phase numbered N+1 in `planned` or `gated`, the prompt opens *that* phase -(`move … ready` + the launch) rather than writing a second one beside it; -when N+1 is taken by a phase that has already run, it says so and offers the -lowest free number instead. The `new` line carries the phase's own `Epic:` and -spells out the title rule: **`new` writes `# — phase N: ` in front -of `--title` itself**, so `--title` takes the tail alone. - -**Run it again** is a ruling first: `rerun` is the only verb that puts a phase +**Accept and open the next task** is two commands in one prompt because they +are one decision: an accept that opens nothing leaves the programme where it +was. With the number gone there is no "N+1" to prefill — the tasks a project +holds are unordered ideas, so the second half offers the project's `planned` +and `gated` tasks to open (`move … ready` + the launch) and otherwise a `new` +line for a task the human names with a slug and a `Summary:`. The `new` line +carries the task's own `Epic:` and spells out the title rule: **`new` writes +`# — ` in front of `--title` itself**, so `--title` takes the tail +alone. + +**Run it again** is a ruling first: `rerun` is the only verb that puts a task back on the board, so the verdict on what came back is what makes the next submission a rerun rather than a repeat. Its `move … submitted --run` line carries the reminder that it is one run per call (`--after ` chains the @@ -628,7 +636,7 @@ the same file `collect`'s checkpoint leg reads: | `pulled_at` | the check-in | UTC `YYYY-MM-DDTHH:MMZ` of the pull that just finished | | `cmd` | the check-in | the pull as a human would type it (`cd && pull`) | | `rc` | the check-in | that pull's exit code — `0`, or the manifest is not written | -| `phases_live` | the check-in | the phase paths that were `submitted \| running` when it ran | +| `tasks_live` | the check-in | the task paths that were `submitted \| running` when it ran | | `schema` | a project's own CLI | `1` where the CLI writes the richer shape; absent = the older `runs`-only one | | `checkpoints` | a project's own CLI | `{"": {"bytes": N, "mtime": ISO}}` | | `runs` | a project's own CLI | `{"": {"checkpoint_bytes": N, "checkpoint_mtime": ISO}}` | @@ -648,7 +656,7 @@ The manifests live **outside** this repository, in the science trees, so `--push` is allowed only when **`gh auth status` succeeds** *and* **this checkout is clean on `main`** — checked before anything is written, since -"clean" stops being true the moment the phases move. That is the cloud/laptop +"clean" stops being true the moment the tasks move. That is the cloud/laptop split and it is also the default: a laptop pushes without asking, a cloud session cannot and says so. The push cuts `claude/checkin-` from a fresh `origin/main`, commits the changed paths explicitly and pushes; @@ -665,14 +673,14 @@ check-in — is the Brain's **cortex conductor**: ```bash pyauto-brain cortex checkin [--dry-run|--apply] [--push|--no-push] [--project KEY] [--skip-pull] [--refreshed ISO] pyauto-brain cortex census [--json] # what is held, by state -pyauto-brain cortex census --by-project # ... by project: folders, open phases, prompts +pyauto-brain cortex census --by-project # ... by project: folders, open tasks, prompts pyauto-brain cortex dashboard --check | --apply # render the two pages -pyauto-brain cortex gates # the gated phases and their refs -pyauto-brain cortex collect [--phase REL] [--pull] [--refreshed ISO] [--apply] [--out F] +pyauto-brain cortex gates # the gated tasks and their refs +pyauto-brain cortex collect [--task REL] [--pull] [--refreshed ISO] [--apply] [--out F] ``` -`checkin` composes the others (above). `collect` with no `--phase` scopes to -**every** phase in `submitted | running` — the scorer on its own. +`checkin` composes the others (above). `collect` with no `--task` scopes to +**every** task in `submitted | running` — the scorer on its own. With no Brain install, or from a workflow: @@ -686,7 +694,7 @@ verb. (`--cortex . dashboard --check` exits 2.) The root is resolved **Two spellings of the same flag.** The conductor writes with `--apply` (the Brain's house spelling); `scripts/cortex.py` writes with `--write`. Every edit -to a phase is `cortex.py`'s either way. +to a task is `cortex.py`'s either way. **The `--check` exit-code contract** (`dashboard_refresh.yml` depends on it): @@ -705,7 +713,7 @@ for exactly that reason. | Workflow | Trigger | Writes | |---|---|---| -| `cortex_check.yml` | push/PR on `phases/ rulings/ batches/ projects.yaml checkin.yaml dashboard.* scripts/ tests/` | nothing (`cortex.py check` + pytest) | +| `cortex_check.yml` | push/PR on `tasks/ rulings/ batches/ projects.yaml checkin.yaml dashboard.* scripts/ tests/` | nothing (`cortex.py check` + pytest) | | `dashboard_refresh.yml` | push to main + PR on the ledger paths and the two pages, nightly **03:35 UTC**, dispatch | `dashboard.md`, `dashboard.html` on main (3-attempt fetch/reset/render/commit/push); a PR run errors instead of healing | | `pages_dashboard.yml` | push to `dashboard.html`, dispatch | nothing in git — publishes `dashboard.html` as the Pages index | | `ledger_merge.yml` | push to `claude/**`, dispatch | merges a ledger-only branch into main | diff --git a/batches/reviews/AGENTS.md b/batches/reviews/AGENTS.md index 4f2b809..9f4ef4e 100644 --- a/batches/reviews/AGENTS.md +++ b/batches/reviews/AGENTS.md @@ -7,5 +7,5 @@ the Cortex does not exist. Never modified, only added. Nothing writes new ones. The review-slot apparatus these came from — the packet page, the scored members, the `-r` sittings, the review-minute budget — was retired on 2026-09-03; the human now rules in the session where the results are -read, and `scripts/cortex.py rule --body ` puts the words +read, and `scripts/cortex.py rule --body ` puts the words into `rulings/`, which is the ledger of record. diff --git a/dashboard.html b/dashboard.html index 6676329..77edaee 100644 --- a/dashboard.html +++ b/dashboard.html @@ -8,12 +8,16 @@ +.fresh{padding:.1rem .9rem;margin:1.2rem 0;background:var(--tint)}.fresh p{margin:.5rem 0}table.map{width:100%;border-collapse:collapse;font-size:.95em}table.map th{text-align:left;color:var(--muted);font-weight:600}table.map td,table.map th{border-bottom:1px solid var(--line);padding:.4rem .5rem .4rem 0;vertical-align:top}.checkin{display:flex;gap:.9rem;align-items:center;padding:.9rem 1.2rem;border:2px solid var(--line);border-radius:.6rem;margin:.2rem 0 1.4rem}.checkin .mark{font-size:2rem;line-height:1}.checkin .label{display:block;font-size:.75rem;letter-spacing:.06em;text-transform:uppercase;color:var(--muted)}.checkin time{font-size:1.6rem;font-weight:700;font-variant-numeric:tabular-nums;display:block}.checkin .note{font-size:.85rem;color:var(--muted)}.checkin.fresh-ok{border-color:var(--ok);background:color-mix(in srgb,var(--ok) 12%,transparent)}.checkin.fresh-ok .mark{color:var(--ok)}.checkin.fresh-bad{border-color:var(--bad);background:color-mix(in srgb,var(--bad) 12%,transparent)}.checkin.fresh-bad .mark{color:var(--bad)}.project h3{font-size:1.35rem;font-weight:700;padding-bottom:.2rem;border-bottom:2px solid var(--accent);letter-spacing:.01em;margin-top:1.6rem}.paths{margin:.2rem 0}.paths b{display:inline-block;min-width:3.6rem}.pathchip{display:inline-block;background:var(--accent);color:#fff;font-family:ui-monospace,SFMono-Regular,Menlo,monospace;font-size:.88em;padding:.12em .5em;border-radius:.3rem;overflow-wrap:anywhere}@media(prefers-color-scheme:dark){.pathchip{background:color-mix(in srgb,var(--accent) 55%,#000)}}.stale{color:var(--bad);font-weight:600} -

PyAutoCortexDashboard

Question. Run. Rule.

Every science phase the Cortex is holding. Tap a phase's 📋 and its next command is on your clipboard. The verdict is always yours — this page hands you the command, never the ruling.

-
  • 0Awaiting ruling
  • 6Running / submitted
  • 0Ready
  • 1Gated
  • 28Recent rulings
+

PyAutoCortexDashboard

Question. Run. Rule.

Every science task the Cortex is holding, one line each under its project. Tap a task's 📋 and its next command is on your clipboard. The verdict is always yours — this page hands you the command, never the ruling.

+
  • 0Awaiting ruling
  • 28Recent rulings

Last updated 2026-09-07.

markdown version · GitHub Page

-

check in since last time

+

check in since last time

Last check-in

Summary

One row per active project — the next thing, what it is holding, and when it last ruled.

- - - - + + + +
ProjectNext phaseAwaitingRunningReadyLast ruling
euclid_dr1_prelim4 submitted010-
inference_programme21 gated0002026-09-04
subhalo_validation2 submitted0502026-09-07
ProjectNext taskAwaitingRunningLast ruling
euclid_dr1_prelimTen real DR1 lenses fitted from the pipeline repo alone01-
inference_programmeWhat Nautilus achieves on mass_pix at f1e8 and f1e5002026-09-04
subhalo_validationDoes rectangular_adapt false-detect a subhalo on the clumpy source052026-09-07

Nothing open

- - - - - - - - - + + + + + + + + +
ProjectStatusPhasesRetire
concrdormantnone
cowls_dianadormantnone
eucliddormantplanned 3
ic50_workspacedormantplanned 1
pj011646dormantnone
profilingdormantnone
slope_hierarchydormantplanned 2
subhalo_simulationsdormantnone
ProjectStatusTasksRetire
concrdormantnone
cowls_dianadormantnone
eucliddormantplanned 3
ic50_workspacedormantplanned 1
pj011646dormantnone
profilingdormantnone
slope_hierarchydormantplanned 2
subhalo_simulationsdormantnone

Projects markdown version

euclid_dr1_prelim

-

Local /mnt/c/Users/Jammy/Science/euclid_dr1_prelim

-

RAL /mnt/ral/jnightin/euclid_dr1_prelim

-

active · both partition · phases: submitted 1

-

Euclid_dr1_prelim — phase 4: DR1 prelim science run — 10 real Euclid lenses in euclid_dr1_prelim on RALsubmitted — euclid_dr1_prelim phase 4 · budget 48:00 · 25 review-min · runs 342301_[0-9], 342314_3

+

Local /mnt/c/Users/Jammy/Science/euclid_dr1_prelim

+

RAL /mnt/ral/jnightin/euclid_dr1_prelim

+

active · both partition · tasks: submitted 1

+

Ten real DR1 lenses fitted from the pipeline repo alonesubmitted — runs 342301_[0-9], 342314_3 · wall 0:00 of 48:00 (0%)

+

tasks/euclid_dr1_prelim/

inference_programme

-

Local /home/jammy/Code/PyAutoLabs/autolens_profiling

-

Mirror /mnt/c/Users/Jammy/Science/inference_programme

-

RAL /mnt/ral/jnightin/autolens_profiling

-

active · both partition · phases: accepted 7 · dropped 11 · gated 1 · planned 4

-

Inference_programme — phase 21: the Nautilus bar on mass_pix — f1e8 (refs convention) and f1e5 (like-for-like)gated — inference_programme phase 21 · budget 4:00 · 15 review-min

-
4 more open phase(s) · plans and issues

phases/inference_programme/ · issues

+

Local /home/jammy/Code/PyAutoLabs/autolens_profiling

+

Mirror /mnt/c/Users/Jammy/Science/inference_programme

+

RAL /mnt/ral/jnightin/autolens_profiling

+

active · both partition · tasks: accepted 7 · dropped 11 · gated 1 · planned 4

+

What Nautilus achieves on mass_pix at f1e8 and f1e5gated — autolens_profiling#218

+

Cluster extended source inference testing gradient based fittingplanned

+

Can spent point-source families be swept out of active outputplanned

+

Are likelihood terms behind gradient search failure on mass_pixplanned

+

Does a gradient search beat Nautilus on mass_pixplanned

+

tasks/inference_programme/ · issues

subhalo_validation

-

Local /mnt/c/Users/Jammy/Science/subhalo_validation

-

RAL /mnt/ral/jnightin/subhalo_validation

-

active · ral partition · phases: accepted 1 · running 2 · submitted 3

-

Subhalo_validation — phase 2: delaunay_adapt_split on pl_eff_0 — the clumpy-source lenssubmitted — subhalo_validation phase 2 · budget 48:00 · 8 review-min · runs 342027_1, 342231_1, 342234_1, 342299_1 — ⚠️ failed runs: 342234_1

-
4 more open phase(s) · plans and issues

phases/subhalo_validation/ · issues

+

Local /mnt/c/Users/Jammy/Science/subhalo_validation

+

RAL /mnt/ral/jnightin/subhalo_validation

+

active · ral partition · tasks: accepted 1 · running 2 · submitted 3

+

Does rectangular_adapt false-detect a subhalo on the clumpy sourcerunning — runs 342237_1, 342240_1, 342311_1 · wall 1:52 of 48:00 (4%) · ⚠️ failed runs: 342240_1

+

Does rectangular_adapt false-detect a subhalo on the outer-component lensrunning — runs 342237_2, 342240_2, 342311_2 · wall 1:52 of 48:00 (4%) · ⚠️ failed runs: 342240_2

+

Does delaunay_adapt_split false-detect a subhalo on the clumpy sourcesubmitted — runs 342027_1, 342231_1, 342234_1, 342299_1 · wall 45:10 of 48:00 (94%) · ⚠️ failed runs: 342234_1

+

Does delaunay_adapt_split false-detect on the outer-component lens and AdaptSplit fixsubmitted — runs 342027_2, 342093_0, 342231_2, 342234_2, 342299_2 · wall 47:05 of 48:00 (98%) · ⚠️ failed runs: 342234_2

+

Does rectangular_adapt behave like delaunay_adapt_split on the clean nullsubmitted — runs 342094_0, 342095_0, 342237_0, 342240_0, 342311_0 · wall 18:01 of 48:00 (38%) · ⚠️ failed runs: 342240_0

+

tasks/subhalo_validation/ · issues

-

Awaiting ruling markdown version

Results are in and nothing is running — the human's verdict is the only thing outstanding. Ordered failures first, then the phases a ruling is required for, then the clean ones.

+

Awaiting ruling markdown version

Results are in and nothing is running — the human's verdict is the only thing outstanding. Ordered failures first, then the tasks a ruling is required for, then the clean ones.

(nothing awaiting a ruling)

-

Running / submitted markdown version

On the queue or on the machine. Wall is what the run lines record at the last refresh, against the phase's own budget.

-

Euclid_dr1_prelim — phase 4: DR1 prelim science run — 10 real Euclid lenses in euclid_dr1_prelim on RALsubmitted — euclid_dr1_prelim phase 4 · budget 48:00 · 25 review-min · runs 342301_[0-9], 342314_3 — wall 0:00 of 48:00 (0%)

-

Subhalo_validation — phase 2: delaunay_adapt_split on pl_eff_0 — the clumpy-source lenssubmitted — subhalo_validation phase 2 · budget 48:00 · 8 review-min · runs 342027_1, 342231_1, 342234_1, 342299_1 — wall 45:10 of 48:00 (94%)

-

Subhalo_validation — phase 3: delaunay_adapt_split on pl_eff_1_outer — the outer-component lens, plus the AdaptSplit fix rerunsubmitted — subhalo_validation phase 3 · budget 48:00 · 8 review-min · runs 342027_2, 342093_0, 342231_2, 342234_2, 342299_2 — wall 47:05 of 48:00 (98%)

-

Subhalo_validation — phase 4: rectangular_adapt on pl_sersic_0 — the RectangularBilinear comparisonsubmitted — subhalo_validation phase 4 · budget 48:00 · 15 review-min · runs 342094_0, 342095_0, 342237_0, 342240_0, 342311_0 — wall 18:01 of 48:00 (38%)

-

Subhalo_validation — phase 5: rectangular_adapt on pl_eff_0 — the clumpy-source lens on the RectangularBilinear comparisonrunning — subhalo_validation phase 5 · budget 48:00 · 8 review-min · runs 342237_1, 342240_1, 342311_1 — wall 1:52 of 48:00 (4%)

-

Subhalo_validation — phase 6: rectangular_adapt on pl_eff_1_outer — the outer-component lens on the RectangularBilinear comparisonrunning — subhalo_validation phase 6 · budget 48:00 · 8 review-min · runs 342237_2, 342240_2, 342311_2 — wall 1:52 of 48:00 (4%)

-

Ready markdown version

Gate cleared, witness registered — everything that could be submitted today.

-

(nothing ready to launch)

-

Gated markdown version

Waiting on development work. Open the references; when they have all closed, cortex.py move ready.

-

Inference_programme — phase 21: the Nautilus bar on mass_pix — f1e8 (refs convention) and f1e5 (like-for-like)autolens_profiling#218 — inference_programme phase 21 · budget 4:00 · 15 review-min

Recent rulings markdown version

The ledger of record, newest first. A verdict recorded only outside the Cortex does not exist.

- - - - - - - - - - - - - + + + + + + + + + + + + +
RulingVerbPhaseBatch
R-20260907-01acceptphases/subhalo_validation/delaunay_adapt_split_pl_sersic_0.md-
R-20260904-05dropphases/inference_programme/multiband_compile_census_completion.md-
R-20260904-04dropphases/inference_programme/mass_pix_gradient_cost_probe.md-
R-20260904-03dropphases/inference_programme/cluster_gradient_search_benchmark.md-
R-20260904-02dropphases/inference_programme/phase5_mesh_gradient_positions_on.md-
R-20260904-01acceptphases/inference_programme/refs_v1_positions_on_completion.md-
R-20260902-10acceptphases/inference_programme/phase4_positions_gate_b2_reuse.md2026-09-02-pm
R-20260902-09acceptphases/inference_programme/phase3_prodigy_reliability_gate_b1_reuse.md2026-09-02-pm
R-20260902-08acceptphases/inference_programme/phase2_nss_mainline_gate_a_reuse.md2026-09-02-pm
R-20260902-07rerunphases/subhalo_validation/delaunay_adapt_split_pl_sersic_0.md-
R-20260902-06rerunphases/subhalo_validation/rectangular_adapt_pl_sersic_0.md-
R-20260902-05rerunphases/subhalo_validation/delaunay_adapt_split_pl_eff_0.md-
RulingVerbTaskBatch
R-20260907-01accepttasks/subhalo_validation/delaunay_adapt_split_pl_sersic_0.md-
R-20260904-05droptasks/inference_programme/multiband_compile_census_completion.md-
R-20260904-04droptasks/inference_programme/mass_pix_gradient_cost_probe.md-
R-20260904-03droptasks/inference_programme/cluster_gradient_search_benchmark.md-
R-20260904-02droptasks/inference_programme/phase5_mesh_gradient_positions_on.md-
R-20260904-01accepttasks/inference_programme/refs_v1_positions_on_completion.md-
R-20260902-10accepttasks/inference_programme/phase4_positions_gate_b2_reuse.md2026-09-02-pm
R-20260902-09accepttasks/inference_programme/phase3_prodigy_reliability_gate_b1_reuse.md2026-09-02-pm
R-20260902-08accepttasks/inference_programme/phase2_nss_mainline_gate_a_reuse.md2026-09-02-pm
R-20260902-07reruntasks/subhalo_validation/delaunay_adapt_split_pl_sersic_0.md-
R-20260902-06reruntasks/subhalo_validation/rectangular_adapt_pl_sersic_0.md-
R-20260902-05reruntasks/subhalo_validation/delaunay_adapt_split_pl_eff_0.md-