Repository navigation
feat(formal): TLA+ model of the repo run cell lifecycle; fix duplicate-cell plans and mixed-execution rows #628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
0687f05
475b47e
2d2fdb4
88111f6
4b5924b
d7d37e8
c3db7ea
4aba5a2
0fa65be
47f6d4b
4d51619
27a835a
452f5cd
7c1b5d4
0f3a601
2691411
d1a5e53
188e2cf
a24c429
2130ad5
18e2755
370be67
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| ### Fixed | ||
|
|
||
| - **`repo run` refuses a plan that names one cell twice** — a repeated `--task` or `--model`, or two | ||
| names that share one cell directory (`a/b` and `a:b`), put two runs in one cell directory; with | ||
| `--jobs 2` each removed the other's files and `result.json` sat beside the other attempt's | ||
| `meta.json` and answer. The run now stops before any agent starts, naming the cell. Names that | ||
| differ only in case are refused on every system, since they share one directory on a | ||
| case-insensitive volume. | ||
| - **`repo report` and `repo compare` refuse an arm and model whose cells hold two executions** — a | ||
| `--force` run with another execution that stopped part way (Ctrl-C, a crash, a failed cell), or a | ||
| harness binary replaced while the batch ran, left cells of two executions that were pooled in one | ||
| row. A batch that reported before can now be refused; the message names both ids, and a `--force` | ||
| run over every arm and model of the batch with the same `--task` and `--reps` clears it. `repo compare` checks only the rows it compares. | ||
|
|
||
| ### Added | ||
|
|
||
| - **`formal/repo_batch`: a TLA+ model of the `repo run` cell lifecycle** — retries, crashes, | ||
| resume, `--force`, Ctrl-C and what the report counts, with TLC configs for the code before the | ||
| fixes, the fixed code, four mutations, a run without fairness and four vacuity witnesses; | ||
| `run.sh` checks each against its expected result. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| # Copyright (C) 2026 Intel Corporation | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| out/ | ||
| RepoBatch_TTrace_* |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| <!-- | ||
| Copyright (C) 2026 Intel Corporation | ||
| SPDX-License-Identifier: Apache-2.0 | ||
| --> | ||
|
|
||
| # Proposal: a model-checking grader for agent tasks | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
AGENTS.md, "What goes in the tree": "Design rationale, status and plans go in the PR description or an issue; the tree has no ADRs or status reports", with Suggestion: move the proposal to an issue or a record in
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Waiting on a decision before I change this: where the evaluator proposal lives. Options: (A) one record under |
||
|
|
||
| Status: proposal, not implemented. It would be a `dokimi:` grader (like the built-in ones in | ||
| `dokimi/repos/`) for tasks whose answer is a change to a system with a fixed formal spec. | ||
|
|
||
| ## Shape | ||
|
|
||
| - **Input**: the task's fixed spec (a `.tla` module with the properties, plus one or more `.cfg` | ||
| files and their `EXPECT` lines), pinned by the task; and the agent's change — either the model | ||
| of the implementation the agent edited, or the code that a task-owned extractor maps to the | ||
| model's constants. | ||
| - **Output**, one of four, in `grade.json`: | ||
| - `pass` — TLC finished every config and each matched its `EXPECT`; | ||
| - `counterexample` — a property was violated: the property name and the trace; | ||
| - `timeout` — the state space was not exhausted within the task's limit; | ||
| - `tool_error` — TLC or the parser failed (syntax error, unknown operator, Java missing). | ||
|
|
||
| ## Rules | ||
|
|
||
| 1. **The agent cannot weaken the spec.** The grader reads the spec, configs and `EXPECT` lines from | ||
| the task's eval tree (pinned in the batch ledger like other grader sources), never from the | ||
| agent's workspace. A change to those paths in the workspace is reported and ignored. | ||
| 2. **The agent cannot swap the checker.** `tla2tools.jar` and the JRE are pinned by SHA-256 in the | ||
| grader and mounted read-only; TLC runs outside the agent's container. The command line | ||
| (`-workers`, `-deadlock`, `-config`) is the grader's, not the task's or the agent's. | ||
| 3. **A timeout is not a proof.** `timeout` and `tool_error` score as not passed and are reported | ||
| apart from `counterexample`, so a slow model is not read as a correct one, and a broken tool is | ||
| not read as an agent failure. | ||
| 4. **Vacuity.** Each task ships witness configs that must be violated; if a witness passes after the | ||
| agent's change (the change made the scenario unreachable), the grade is `counterexample` with | ||
| the witness named. | ||
| 5. **A pass is not a quality score.** It means: in this bounded instance, under the stated fairness | ||
| assumptions, the listed properties hold. The report shows it as its own measure next to tests and | ||
| any judge, never folded into one number, and names the instance bounds. | ||
|
|
||
| ## Limits | ||
|
|
||
| - Bounded: only the constants in the configs are checked. | ||
| - The model-to-code link is as good as the extractor or the human mapping (the README's action → | ||
| code table); a correct model of wrong code passes. | ||
| - Liveness holds only under the fairness the spec assumes. | ||
Uh oh!
There was an error while loading. Please reload this page.