outerloop-science 0.4.0__tar.gz → 0.5.0__tar.gz

{outerloop_science-0.4.0 → outerloop_science-0.5.0}/.pre-commit-config.yaml

@@ -14,7 +14,7 @@ repos:
       - id: check-toml
 
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.16.6
+    rev: v0.17.1
     hooks:
       - id: ruff-check
         args: [--fix]

{outerloop_science-0.4.0 → outerloop_science-0.5.0}/CHANGELOG.md

@@ -6,6 +6,39 @@ Versions follow [SemVer](https://semver.org).
 
 ## [Unreleased]
 
+## [0.5.0] - 2026-10-23
+
+### Upgrading
+
+No operator action is needed before upgrading; details in each entry.
+
+What changes for runs in flight: kernel comments, issues and pull requests
+start carrying `<!-- outerloop:kernel -->`; the first tick republishes
+`climb/status.json` in the new shape; a resumed Claude session captured
+before the upgrade still overstates its cost.
+
+Before rolling back: remove `slots` keys from `limits.toml`, and let local
+jobs on GPU UUID ids (`GPU-...`) finish.
+
+### Changes
+
+- Docs for personal-token mode: the install guide's personal-mode section (setup, how kernel posts are told apart, what GitHub no longer enforces, token reach, switching modes), the safety defaults in `operate.md`, `OUTERLOOP_IDENTITY` in the environment reference, `init --personal` in the CLI reference, and `personal: true` in the reviewer setup.
+- Personal-token mode is selectable: `outerloop init --personal` takes the token `gh auth token` prints and writes it 0600 to the default PAT file (or uses a token file given with `--pat-file`), records its login as `OUTERLOOP_BOT_LOGIN`, and writes `OUTERLOOP_IDENTITY=personal`; `start` and the deploy step carry the setting into every tick. The kernel then posts as the person, so its own posts are told apart by the `outerloop:` marker rather than by login. The setup prints the trade-offs: no notifications for the kernel's activity, the `gh` token's repository-wide reach, and the reviewer workflow's `personal: true`. Upgrading: switching a personal deployment back to the App means releasing or closing claimed issues first — their claim comments were posted as the person, and the App's login check no longer counts them.
+- One rule, `forge.is_kernel_post`, now decides whether a comment, issue or pull request is the kernel's, wherever the kernel asks. In personal mode (`OUTERLOOP_IDENTITY=personal`) the login is the person's, so a post is the kernel's only when its body also carries an `outerloop:` marker. Alias logins keep the login check alone. Kernel comments, issues and pull requests now carry `<!-- outerloop:kernel -->` unless they already carry a marker. When the kernel arms auto-merge it records the PR in the run's stage (`auto_merge_armed`) and clears the record once it disarms or sees auto-merge off; under the auto dial it withdraws only an arm that record claims, so a human's later arm is left alone. Upgrading: kernel posts now carry a marker, which an older kernel ignores. A stage without an `auto_merge_armed` record (every run armed before the upgrade) keeps the old `enabled_by.login` rule outside personal mode, so a PR the kernel armed before the upgrade is still withdrawn under the auto dial; rolling back ignores the field.
+- The `siblings` view now shows each sibling's research instead of its last chat line: the run's stated hypothesis, its three most recent launches with `--why`, state and result line, the candidate score from the kernel's own gate measurement (never the agent's claim), and its PR, plus the target's five most recent endings with outcome and report title. `climb/status.json` gains `best_result` and `launches` per live run and a top-level `ended` list. Upgrading: no action needed; a snapshot written before this change reads as before (no launches, score or endings) and the first tick republishes it once in the new shape; rolling back is safe because an older reader ignores the added fields.
+- Session records and the session index now carry the Claude Code version that ran, read from the binary's resolved path (the native installer's `versions/<x.y.z>` and the kernel's managed `harnesses/claude/<x.y.z>/` installs; the pin is not used, since an operator can point the kernel at any binary), so a resumed Claude session prices its cumulative resume totals once at the newest leg when it ran on Claude Code 2.1.277 or later. Codex is unchanged, and a Claude entry without a usable version keeps summing its legs (#515). Upgrading: no action needed; index entries written before this change carry no version, so a resumed Claude session captured before the upgrade still overstates its cost until those entries age out.
+- `outerloop init` warns when the Claude or Codex CLI it finds is older than the pinned version and names `outerloop harness upgrade`, and says when the pre-PR panel stays off for lack of an image. The install guide covers seeding a private repository into the local forge.
+- `outerloop pr merge` on the local forge authors the merge commit with the operator's git identity from system and global config (a repo-local identity in the directory it runs from is ignored); automatic merges keep the kernel's. Candidate snapshot commits are named `candidate snapshot: <run id>` instead of `dispatch snapshot`.
+- Add an internal `Forge` seam behind the kernel's code-host operations; `OUTERLOOP_FORGE` accepts only `github` for now (no behavior change).
+- Add the local forge backend's transport, refs and files over bare repositories (clone, branch and file reads and compare-and-swap writes); `OUTERLOOP_FORGE=local` is not selectable until pull requests, threads and issues exist.
+- Add the local forge backend's records on `refs/outerloop/records`: pull requests, comment threads and the kernel's issues, with merge-commit transactions and recovery of merges made outside the kernel; user-visible inbox and self-merge text takes the forge's name.
+- The local forge is selectable: `OUTERLOOP_FORGE=local` builds it from the state root, entry points need no GitHub credential or bot login, `outerloop init --forge local` bootstraps the bare repository, and `outerloop pr` lists, shows, comments on, merges and closes its pull requests.
+- Local compute's GPU pool follows the loop's own `CUDA_VISIBLE_DEVICES`: when it is set at startup, those ids are the pool (jobs still get a subset), so two deployments on one host can be given disjoint GPUs. `OUTERLOOP_LOCAL_GPUS` caps the list, keeping the first ids; empty or `-1` means no GPUs. Jobs never see GPUs outside the loop's view: a job without an allocation inherits the loop's `CUDA_VISIBLE_DEVICES`. Fix: on local compute, the evaluated command now sees its job's GPU mask; the eval script's scrubbed environment (`env -i`, or apptainer `--cleanenv`) used to drop it, so evaluated code saw every GPU on the host. Slurm jobs are unchanged.
+- Upgrading: an existing pool file (`gpus.json`) reads correctly, since holder keys stay the GPU index strings. Before rolling back to an older kernel, let jobs on non-integer ids (`GPU-...` UUIDs) finish: the older kernel cannot sort those holder keys.
+- `limits.toml` accepts a per-target `slots` list (`[targets."owner/repo"]`, `slots = ["agent-04"]`): self-initiated runs take the first free listed agent identity, in order, instead of the lowest free `agent-01..agent-<width>`, so an operator can keep a slot's research line and author binding. Slots never add capacity (the attempt width still caps concurrency), running runs in unlisted slots are untouched, and `outerloop limits` shows the list. Without `slots`, behaviour is unchanged.
+- Upgrading: existing `limits.toml` files need no change. Remove any `slots` key before rolling back to an older kernel, which treats it as unknown and fails the file closed.
+- Refresh the toolchain within the existing bounds: pydantic 2.14.1, pydantic-core 2.50.1, ruff 0.17.1 and pre-commit 4.7.0; the ruff-pre-commit hook matches the locked Ruff. No source formatting or lint changes were needed.
+
 ## [0.4.0] - 2026-10-20
 
 ### Upgrading

{outerloop_science-0.4.0 → outerloop_science-0.5.0}/CITATION.cff

@@ -13,5 +13,5 @@ authors:
 repository-code: "https://github.com/outerloop-science/outerloop"
 url: "https://outerloop.science"
 license: Apache-2.0
-version: 0.4.0
-date-released: "2026-10-20"
+version: 0.5.0
+date-released: "2026-10-23"

{outerloop_science-0.4.0 → outerloop_science-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: outerloop-science
-Version: 0.4.0
+Version: 0.5.0
 Summary: Autonomous research agents that improve the benchmark you point them at, one verified pull request at a time
 Project-URL: Homepage, https://outerloop.science
 Project-URL: Repository, https://github.com/outerloop-science/outerloop

{outerloop_science-0.4.0 → outerloop_science-0.5.0}/docs/design/accelerators.md

@@ -35,8 +35,9 @@ placed and capped before any TPU contract is accepted.
 - **Operator limits.** `limits.toml` `max_gpus`, counted from one
   `squeue --me --json` snapshot by parsing `gres/gpu` TRES, attributing jobs to
   this fleet by run id.
-- **Local backend.** `nvidia-smi` detection (or `OUTERLOOP_LOCAL_GPUS`),
-  `CUDA_VISIBLE_DEVICES` pinning.
+- **Local backend.** `nvidia-smi` detection (or `OUTERLOOP_LOCAL_GPUS`), the
+  loop's own `CUDA_VISIBLE_DEVICES` when it is set, `CUDA_VISIBLE_DEVICES`
+  pinning.
 - **Surfaces.** Briefs, wake lines, refusals, `budget.json`
   (`gpu_hours_remaining`), `outerloop status`, `outerloop limits` and the board
   carry GPU-named fields.

outerloop_science-0.5.0/docs/design/forge.md

@@ -0,0 +1,318 @@
+# A forge interface with a local backend
+
+Status: proposed for the release after 0.4. Tracking issue: #488. A
+personal-token mode for GitHub follows on top of it (end of this note).
+
+## Problem
+
+The kernel reaches GitHub in three roles that share one client today:
+
+- **Code transport**: clone, fetch and push of line branches, candidate
+  branches and the base, through `Workspace` with a credential scoped to
+  `https://github.com/`.
+- **Review surface**: pull requests (open, draft, body edits, ready for
+  review, auto-merge, merge, close), thread comments, reviews, check runs.
+- **Intake and record**: issues as work orders, claim markers, the
+  research-log branch (ledger, reports, board) written through the git-data
+  API, and pointer comments on the research-log issue.
+
+All of it goes through `GitHubClient` (`github.py`), which about a dozen
+modules call. Two costs follow. A measured result depends on GitHub's
+availability and rate limits; outages have already aborted runs. And every
+deployment needs a hosted repository and GitHub access through an App or a
+machine-user token, which some labs cannot or will not set up. Adopters
+report the App setup as the main friction of getting started.
+
+Large studies feel all of this at once. A study of hundreds of runs needs a
+hosted repository per cell, shares one API rate limit, and loses runs to any
+outage. Locally a cell is a directory that a study script creates and
+deletes.
+
+## Scope of the first version
+
+The first version serves unattended deployments and studies, where the
+auto merge dial is the norm: the kernel merges a head only after its own
+measurement and the judge panel's approval, and people review the record
+afterwards. It keeps what that needs and what the kernel writes on its own:
+
+- code, line and candidate branches and the research-log branch (ledger,
+  reports, board) on a bare repository;
+- pull-request records with real merge evidence;
+- comment threads as an append-only log, so agent and kernel posts have a
+  place to land and a person's reply reaches the author's inbox;
+- issue records that the kernel creates, comments on and closes (the
+  research-log issue and contract alarms need them);
+- the identity seam, trivial locally;
+- `outerloop pr list`, `show N`, `comment N`, `merge N` and `close N`.
+
+It leaves out human work orders: issue intake, the steward lane and claim
+markers. Work comes from the kernel's self-initiated lanes, and
+`outerloop message` steers a live run. The manual dial works, but nothing
+notifies a person that a pull request waits; `outerloop status` and
+`outerloop pr list` show it.
+
+Every record is kept in git (below), so a deployment's or a study's full
+history of pull requests, threads and outcomes can be read back, mirrored
+or replayed later.
+
+## Design
+
+### One interface, two backends
+
+A `Forge` Protocol, selected the way `Compute` is (`compute.py`):
+`OUTERLOOP_FORGE=github` (the default) or `local`. `GitHubForge` wraps the
+existing client and changes no behavior. `LocalForge` implements the same
+verbs over a bare git repository and JSON records on the deployment's
+shared filesystem. `OUTERLOOP_FORGE` joins the keys `start` exports and the
+deploy step carries into every tick.
+
+One factory builds the forge at every entry point (the tick, attempt and
+steward jobs, and the CLI) and supplies three things callers take from the
+client or the environment today:
+
+- **Workspaces.** Clone URL and credential come from the forge. This
+  replaces `target_clone_url` (`attempt.py`) everywhere it is used: run
+  wakes, publish, `finish_run`, the tick's mid-leg sync and the steward.
+- **Kernel identity.** `bot_login` stays load-bearing: commits take their
+  author from it, and intake and the steward refuse to run without it. On
+  GitHub it is the App or bot login, as today; locally the factory supplies
+  `outerloop`.
+- **Secrets and dry run.** `forge.secrets()` feeds redaction, replacing the
+  direct `github.auth.token()` read in the tick; `forge.dry_run` replaces the
+  direct attribute read in the ledger.
+
+Startup gates become backend-aware. Servicing needs a home, a target and an
+image on every backend; the credential and bot-login gate applies to
+`github` only.
+
+The kernel's verbs, grouped by role:
+
+| Role | Verbs |
+|---|---|
+| Transport | clone URL and credential for a `Workspace` |
+| Refs and files | `default_branch`, `branch_head`, `branch_sha`, `head_contains`, `commit_tree`, `get_tree`, `get_file`, `get_file_content`, `list_directory`, `create_ref`, `ensure_branch`, `put_file`, `put_files` |
+| Pull requests | `create_pull`, `get_pull_request`, `find_open_pull_for_head`, `update_candidate_row`, `append_pull_body`, `mark_ready_for_review`, `arm_auto_merge_when_review_required`, `disable_auto_merge`, `allowed_merge_methods`, `merge_pull`, `close_issue` |
+| Threads | `list_comments`, `comment`, `list_pr_reviews`, `list_pr_review_comments` |
+| Issues | `list_open_issues`, `create_issue` (with labels) |
+| Checks | `list_check_runs` |
+| Identity | `is_kernel_post`, `qualifies` (below) |
+| References | `ref_for(kind, id)`: a stable reference and an optional link |
+
+`get_pull_request_diff`, `create_pr_review`, `update_issue` and
+`job_log_tail` serve only the GitHub Actions posting CLIs (or are reached
+only through a GitHub check run), so they stay on the GitHub client and out
+of the Protocol. Four client methods have no caller (`create_pr`,
+`get_issue`, `get_pull_request_files`, `upsert_comment`) and are deleted.
+
+### Shapes and errors
+
+Return values keep the shapes callers read today, so the ledger observer,
+bless and merge checks, intake and the steward read local records unchanged:
+
+- **Pull request**: `number`, `state`, `merged`, `merged_at`,
+  `merge_commit_sha`, `draft`, `mergeable_state`, `user.login`, `html_url`,
+  `labels`, and nested `head.sha`, `head.ref`, `base.ref`. `head.sha` and the
+  base tip are read from the live refs on every call, so a follow-up push is
+  seen at once.
+- **Issue**: `number`, `title`, `body`, `user.login`, `author_association`,
+  `labels[].name`, `created_at`.
+- **Comment**: an increasing integer `id`, `user.login`, `body`,
+  `author_association`, and an ISO `created_at` (the steward releases stale
+  claims by age).
+- **Reads at a ref** follow the real client: a branch or a sha; `get_file`
+  raises on a missing file and `get_file_content` returns `None`; regular
+  files only; `get_tree` reports `truncated` false; `branch_head` returns
+  `""` for a missing branch and `None` on failure; `put_file` and `put_files`
+  return what the client returns.
+- **Errors**: a missing branch, file or record raises the client's error
+  with `status` 404. Several callers read a 404 as "absent" (the ledger, the
+  board, `close_if_done`, base-moved checks); any other error reads as an
+  outage and stalls them.
+
+Contract reads use `default_branch` instead of the literal `main` the tick
+passes in two places today, so a local repository with another default
+branch still loads its contract. User-visible text that names GitHub (the
+inbox's member label, its conflict line, the self-merge status comment)
+takes the forge's name instead.
+
+### The local backend
+
+- **Bootstrap.** `outerloop init` creates the bare repository at
+  `$OUTERLOOP_ROOT/forge/<owner>/<repo>.git` with `git clone --bare` from an
+  existing repository (a path or URL), or `git init --bare` with a first
+  commit of a given directory. Its default branch is recorded.
+- **Records in git.** `pulls/<n>.json`, `issues/<n>.json` and
+  `threads/<n>/<id>.json` are files on a dedicated ref in the bare
+  repository (`refs/outerloop/records`), written with the same
+  compare-and-swap commit the ledger uses on the research-log branch. Every
+  change is a commit, so nothing is overwritten, any past state can be read
+  back, a crash leaves either the old commit or the new one, and
+  `git clone --mirror` backs up code and records together. A conflicting
+  writer retries on the new tip. Issues and pull requests share one number
+  sequence, as on GitHub, and `close_issue` closes either kind. Thread
+  entries are append-only with increasing integer ids. Closing is always
+  written explicitly: `close_if_done` reads `state == "closed"` to end a
+  rejected run.
+- **Transport.** A path URL with no credential (`Workspace` already accepts
+  `auth=None`). Filesystem permissions are the access control. The bare
+  repository sits outside every path a session can see. Every clone a
+  session can see uses `--no-local` with no alternates, so it shares no
+  object files with the bare repository; today only the single-branch clone
+  passes `--no-local`, so the default `Workspace.clone` and the channel
+  bootstrap clone change too. A contained session cannot reach the state
+  root; an uncontained one can, which the install guide's uncontained
+  trade-offs will say.
+- **Line snapshots.** `_push_line_snapshot` returns early when a workspace
+  has no credential. It changes to ask whether the forge has a transport,
+  and the forge reaches it through `finish_run` as well as the run legs, so
+  local snapshots are pushed on every path.
+- **Pull requests.** Opening one pushes the head branch first, as on GitHub.
+  `mergeable_state` is computed when read and cached by the head and base
+  shas: `clean` when the head contains the base tip, `behind` when it does
+  not but a trial merge succeeds, and `dirty` only when the trial merge
+  conflicts, which is what the inbox treats as a conflict.
+- **References.** `html_url` holds the local reference and still ends in
+  the pull-request number, which the kernel parses from it.
+- **Merging.** `allowed_merge_methods` returns `["MERGE"]`. `merge_pull`
+  builds a merge commit from the expected head sha and moves the base in one
+  git ref transaction (`git update-ref --stdin`): verify the head branch
+  still points at the expected sha, then update the base from its old tip.
+  Either both checks pass and the base moves, or nothing changes. The record
+  is written after the ref moves.
+- **Merges made outside the kernel.** A person may merge with plain git and
+  push, and a process may die between moving the base and writing the
+  record. Either way the next read of an open record whose head the base
+  now contains records the merge: `merge_commit_sha` is the commit on the
+  base whose second parent is the head, or the head itself after a
+  fast-forward. The ledger needs that commit and compares its tree with the
+  measured one, so it is recorded once and kept even if the branch later
+  moves or is deleted. Squash and rebase merges leave no such commit and
+  are not supported. (`head_contains(repo, base, head)` asks whether the
+  head contains the base; this check is the reverse call.)
+- **Auto-merge.** Nothing is armed locally:
+  `arm_auto_merge_when_review_required` returns `False` and
+  `disable_auto_merge` reports disarmed. Under the auto dial the kernel
+  merges a blessed head through `merge_pull` with the same bless rules as on
+  GitHub. There are no required checks, so the stale-base guard is the
+  head-contains-tip test.
+- **Checks and reviews.** `list_check_runs`, `list_pr_reviews` and
+  `list_pr_review_comments` return nothing. The inbox reads them to pass
+  CI results and Actions review rounds to the author; locally there are
+  none.
+
+### People: review and merge from the CLI (open question 1)
+
+A small `outerloop pr` group: `list`, `show N` (the record and its thread),
+`comment N`, `merge N` and `close N`. These commands write the same records
+the kernel reads, so a person's comment reaches the author's inbox and the
+agent's and kernel's posts are readable in the thread, as on GitHub. Diffs
+come from `git diff` against the bare repository. No web view in the first
+version.
+
+Human work orders come later: `outerloop issue new [--label L]` and
+`outerloop issue comment N`, with issue intake, the steward lane and claim
+markers. The labels are the kernel's own: `outerloop:steward` routes an
+issue to the steward lane and `outerloop:task` vouches for a work order.
+
+### Ledger, board, research log (open question 2)
+
+The ledger, reports and board go through refs-and-files verbs and work
+unchanged. Research-log publication also creates and comments on the
+research-log issue; locally those become records like any issue. Links are
+hard-coded to `github.com` today in the tick (the research-log pointer and
+the rolling issue body), `progress.py`, `ledger_branch.py` and
+`maintain.py`; they move to `ref_for`, so they point at the forge in use.
+
+### Identity, and who merges (open question 3)
+
+`is_own_login(author, bot_login)` becomes `forge.is_kernel_post(item)` at
+the call sites that judge an issue, comment or post:
+
+- **GitHub with an App or bot account**: the login check, aliases included,
+  as today.
+- **Local**: records the kernel writes carry the author `outerloop`; the CLI
+  writes the operator's user name.
+- **GitHub with a personal token** (follow-up): the kernel and the person
+  share one login, so a post is the kernel's when it comes from that login
+  and carries an `outerloop:` marker. Every kernel post gets a marker for
+  this; most already have one.
+
+Two call sites judge a pull request's author rather than a post (the
+reviewer's and the verifier's skip rules). They run in GitHub Actions only,
+and read `user.login` from the pull request.
+
+One ownership check has neither: `_observe_auto_pr` disarms auto-merge only
+when the kernel armed it, read from `auto_merge.enabled_by.login`. With a
+shared login that cannot tell the kernel from the person, so the follow-up
+records the arming itself (pull request number and head) in the run's stage
+when the kernel arms, and compares against that.
+
+`author_association` checks become `forge.qualifies(item)`: author standing
+only. Locally every person-written record qualifies, since only people with
+write access to the forge directory can write one. Each lane keeps its own
+rules on top: intake also accepts its vouching label, the steward lane
+requires author standing, and the verifier still trusts kernel replies and
+marked verifier posts.
+
+Who merges is unchanged on every backend. Under the manual dial the kernel
+never calls `merge_pull`; on GitHub it only arms auto-merge behind a
+required human review, and locally it arms nothing. Under the auto dial the
+kernel merges blessed solver heads, and steward pull requests stay a
+person's to merge. Reviews are comments only.
+
+Locally none of this is enforced by permission. The kernel and the people
+share the filesystem, so anyone who can write the forge directory can write
+a record with the author `outerloop`, including a claim marker that GitHub's
+bot identity makes unforgeable. That is the trust the operator already gives
+everyone with write access to the state root.
+
+### Migration (open question 4)
+
+One backend per deployment, chosen at `outerloop init`. Moving between
+backends is not supported in the first version. Branches can be pushed to
+another remote by hand. Records stay recoverable because they live in git:
+a mirror keeps them, and a later tool can replay them into another forge.
+
+## What stays GitHub-only
+
+The advisory review and verifier workflows run in GitHub Actions on
+`pull_request_target`, and the maintenance digest posts issues there. On
+the local backend they do not run. The kernel's own review panel and gate
+run inside the kernel and are unaffected.
+
+## Build order
+
+Each step is one PR with its tests:
+
+1. The `Forge` Protocol, `GitHubForge` around the existing client, the
+   factory at every entry point (workspaces, kernel identity, secrets, dry
+   run), `OUTERLOOP_FORGE` in the deploy and start key lists, callers typed
+   to `Forge`, contract reads at `default_branch`, the four dead methods
+   removed. No behavior change.
+2. `LocalForge` bootstrap, refs, files and transport, with `--no-local`
+   session clones, transport-gated snapshots and the 404 error contract; the
+   ledger, research log and board on a bare repository; links through
+   `ref_for`; `outerloop init` offers the local backend.
+3. Records on `refs/outerloop/records`: pull requests, threads and the
+   kernel's issues; the merge transaction and the recording of merges made
+   outside the kernel; the identity seam (`is_kernel_post`, `qualifies`) on
+   both backends; the forge name in user-visible text; the `outerloop pr`
+   commands; docs.
+
+Later, when someone needs them: human work orders (the `outerloop issue`
+commands, intake, the steward lane and claims on the local backend).
+
+Then the personal-token mode: `init` offers "use my GitHub login" and writes
+`gh auth token` to the PAT file, the marker rule from step 3 applies,
+auto-merge arming is recorded in the run's stage, and PR bodies and commit
+trailers name Outerloop as the author. Its docs state the trade-offs: the
+person cannot approve their own agents' pull requests, so a required-review
+rule needs a second reviewer; the kernel's restraint about merging holds by
+its code, not by permission; and a fine-grained token limited to the target
+repository is safer than the `gh` login token.
+
+## Not in the first version
+
+A web view, hosted alternatives such as Gitea or GitLab (later backends of
+the same interface), migration between backends, CI checks, inline reviews
+and job logs on the local backend, and the Actions-based workflows on it.

{outerloop_science-0.4.0 → outerloop_science-0.5.0}/docs/design/lifecycle.md

@@ -119,8 +119,10 @@ The author's session never sees a raw comment body outside a fence, never
 sees the seed, and never sees a message the kernel did not write into the
 inbox. Advisory findings are delivered like blocking ones; the author decides
 what to do with them. The sibling view is refreshed at every wake, not only
-at start, and `siblings` shows each live run's hypothesis and PR link, including
-runs in review. The hypothesis survives publication for the rest of the run.
+at start, and `siblings` shows each live run's stated hypothesis, its recent
+launches with their reasons and result lines, its best measured score and its
+PR link, including runs in review, plus the target's recent endings. The
+hypothesis survives publication for the rest of the run.
 When to check the view — before choosing a direction and again before a
 submit, taking an unused direction unless its angle is distinct — is guidance,
 not a kernel step: the brief states the refresh, the pack carries the advice.