Define the integrated Scholarr product sprint

This commit is contained in:
justinzeus 2026-10-03 00:02:22 +02:00
parent 41e8714ca3
commit 0e22839ae4
7 changed files with 361 additions and 145 deletions

View file

@ -1,7 +1,7 @@
# Scholarr agent brief
This file is the canonical brief for every coding agent working in this repository. Read it and
`TASKS.md` before making changes.
For sprint work, read `SPRINT.md` before changing the repository. It is the
single product, decision, provider-safety, and execution reference.
## Product
@ -41,14 +41,11 @@ Do not silently change a locked decision. Record a proposed change as open and a
## Decision record
On tank, the authoritative project runbook is:
`SPRINT.md` governs an explicitly owner-approved sprint. The historical charter
and identity/calibration/testing records live in `runbooks/rewrite/`.
`/opt/stacks/server-docs/runbooks/scholarr-rewrite/README.md`
It owns doctrine, locked decisions, empirical calibration results, and project state. Its
companion files own the identity model and testing strategy. This brief is self-contained for
agents without tank access, but any state or design decision reached on tank must also be written
to that runbook in the same session.
Track acceptance and next actions in Forgejo. Record sprint implementation
decisions in `SPRINT.md`; do not add another plan or a separate freeze queue.
## Frozen UI contract
@ -67,10 +64,11 @@ are expected.
## Work process
- Work through `TASKS.md` in order. Each task has a goal and acceptance criteria.
- Freeze one spec at a time. Decided items are labeled decided; open items remain open for owner
review.
- Do not start implementation for an area whose spec is not frozen.
- Work the integration issue's acceptance items in order, against `SPRINT.md`.
- Preparation does not authorize execution. Start only after the owner approves
the concrete nightly plan and explicitly says to launch.
- An approved sprint replaces separate spec-freeze ceremonies with the bundled
defaults in `SPRINT.md`. Preserve locked requirements; report conflicts.
- Keep commits focused and use plain imperative commit messages without trailers.
- Stage only files you changed.
- Do not use em dashes in prose, code comments, commit messages, or user-facing copy.