Files
nisse/nisse-review
dongarandClaude Opus 5.5 dd060566b2
CI / checks (push) Skipped
CI / checks (pull_request) Successful in 2m54s
CI / e2e (pull_request) Successful in 4m20s
The call record: every model call, for the operator's study (M6.6a)
nisse-core records each model call of every agent into a file beside its
state store (<state>.calls.db), for the status page (L7, X6):

- the request body exactly as sent (never headers), the raw response with
  its reasoning, the model asked and the one that answered, time, tokens
  and llama-server's own prompt reuse (timings.cache_n);
- its work item, role, run and purpose: Driver.run and nisse-dev's
  delegation loop open runs, nested; compaction, expert consults, the
  classifier and the go-ahead reader label their calls;
- provenance, worked out in BudgetedClient by comparing the events at
  each stage: each event sent with its log id and content as sent, which
  a compaction replaced, which fitting shortened (by how much) and
  dropped.

Content is stored once by hash, compressed. It is diagnostic only: the
agent never reads it, a failed write is logged once and recording stops
while the call goes on, and the file is deleted when the agent starts,
so its layout never migrates; CallReader refuses a layout it doesn't
know. While recording, the system prompt ends with one sentence saying
so. `call_record: false` in either agent's YAML turns it off.

The benchmark records each run beside that run's own state store, and
`--keep-runs DIR` keeps both for the page.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk
2026-10-24 06:28:53 +00:00
..

nisse-review

The Review Agent (Part R of the architecture): it reviews every pull request that is ready, in the repositories its Gitea account can read, and posts its review on the PR as a COMMENT review. It reads and comments; it never changes code, approves, or requests changes.

A thin application over nisse-core, with its own small scheduler:

  • config: its YAML configuration (nisse-review.example.yaml).
  • state: its state store, and a review item (one per PR).
  • scheduler: the duty (ready PRs), one review at a time, recovery after a crash.
  • clones: each repository as a git clone kept between runs (the latest one), checked out at the PR's head and, when read, its base.
  • reader: those trees, read-only, as the run's executor.
  • review: one review run, and posting it.
  • build, main: putting it together, and the access check at startup.

Bring-up on the development VM: scripts/review-bringup.sh.