[Alex1990]

Implements 05 §7 stage A1 (自动只报告) for tiny-oss: the event-triggered headless host — Actions as scheduler + sandbox, R2 as the state layer.

What lands

File	Role
.github/workflows/loop.yml	Single serial workflow (concurrency: {group: loop}) = scheduler + sandbox. Triggers: issues / issue_comment / pull_request / pull_request_review / pull_request_target(closed) / release / schedule / workflow_dispatch.
scripts/loop/entry.mjs	Orchestrator: route → inbox | metrics | run. Single writer for closing a run.
scripts/loop/shared/state.mjs	State-layer primitives (outcome map, stage whitelist, locks, acceptance, SUMMARY).
scripts/loop/shared/route.mjs	Event → decision, pure functions (17/17 routing cases verified offline).
scripts/loop/shared/agent.mjs	pi driver: prompt, spawn, usage accounting, failure classification.
scripts/loop/shared/r2.mjs	R2 sync via the runner's preinstalled AWS CLI.
scripts/loop/run.mjs	Now consumes the shared library; adds --write-level.

Write boundary (owner decision: strict report)

LOOP_WRITE_LEVEL=report by default. Runs write the state layer + a report; every GitHub write action (labels, comments, closing, opening a PR) is listed as a checklist in the report and in the Actions Step Summary, never executed. workflow_dispatch carries execute_writes=true so the L2 write path can be rehearsed in a controlled moment before it is left on.

Engine

pi (@earendil-works/pi-coding-agent@0.85.1) — three required verifications passed: headless --mode json JSONL event stream, DeepSeek built in, ~21 MB with no install scripts. --approve is mandatory or project-local resources are silently ignored. pi has no built-in permission gating, so the job's permissions: block is read-only and write credentials live only in default-branch contexts.

Two findings worth review

1. R2 has no object versioning (checked against the R2 docs index and release notes; the nearest feature is bucket locks = retention, not history). 05 §3.1 assumes it. Consequence: deletes are not revertible, so push deliberately omits --delete and syncing is overwrite-plus-add only.
2. .gitignore:4 (lib) matches at any depth, so the shared library under scripts/loop/lib/ would never have been committed and the runner checkout would have crashed. Renamed to scripts/loop/shared/; the existing ignore rule is untouched.

Verified locally

CLI report boundary performs zero GitHub writes · run closing is idempotent · stage→outcome whitelist enforced · event routing 17/17 · acceptance writes deduplicated by taskId+event+pr · system-level sweep/retro-scheduled runs work (task-less) · a stubbed engine exercising prompt → result.json → state transition → Step Summary with token accounting · provider flake classifies as retry instead of filling the human inbox.

Before this can run

Needs R2 + LLM secrets and a one-time state-layer seed — steps are in scripts/loop/README.md ("One-time setup"). The pi --list-models deepseek line printed on every run settles the one open question (deepseek/deepseek-flash is unconfirmed against pi's built-in catalogue).

A1 acceptance list (rewritten for the report boundary, since the drift criterion is vacuous when nothing is written) is in scripts/loop/README.md.

[github-actions]

Coverage

Metric	%	Covered / Total
Lines	90.19%	1003/1112
Statements	89.06%	1083/1216
Functions	91.03%	193/212
Branches	76.43%	519/679

[Alex1990]

The failing loop check is expected — and it already validated three things

loop runs on this PR (a PR is a triage surface), reaches the first credential-dependent step, and stops there. No secrets exist yet. That failure point is the designed one:

Step	Result
Set up job / checkout / setup-node / pnpm install --frozen-lockfile	pass
Install engine (pi)	pass — added 132 packages in 6s, pi --version → 0.85.1
Pull state from R2	fail — secrets absent (correct place to stop)
Run stage	skipped — a failed pull must not run the stage
Push state to R2 (if: always())	fail — same cause
Upload session transcripts	pass

Three things now verified by real execution rather than by reading docs:

1. pi installs on ubuntu-24.04 in ~6s (~21 MB, 132 packages, no install scripts) — the engine choice holds on Actions, well inside the job budget.
2. A failed pull aborts the run instead of letting an empty local state/ reach the push. This was the main data-loss risk, since R2 has no object versioning.
3. if: always() really does push after a crash, so a cancelled or timed-out job still lands its last state instead of losing it.

One finding from that same log: pi --list-models deepseek prints No models available. Use /login to log into a provider or API key — pi's model catalogue is credential-gated, so LOOP_MODEL=deepseek/deepseek-flash cannot be confirmed until DEEPSEEK_API_KEY exists. The value is printed on every run, so the first configured dispatch settles it. That log also showed a missing key would have been classified as an agent failure and pushed the task into the human inbox; credential/config errors now classify as retry (commit 5958e68).

To turn this green

Secrets (Settings → Secrets and variables → Actions): R2_ACCOUNT_ID, R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY, R2_BUCKET, DEEPSEEK_API_KEY (+ LOOP_GH_TOKEN, unused while report-only). Bucket creation, the scoped token, and the one-time seed are in scripts/loop/README.md → "One-time setup".

Until those exist, every push to this branch will show a red loop check. That is this workflow working as specified, not a broken PR.

[Alex1990]

Design change: one R2 bucket per repository (commit 8eb59fd)

Answering "what happens when I add a second repo?" — and the answer turned out to constrain the design, so the bucket layout changed.

An R2 API token can be scoped to a bucket, but never to a key prefix. The access-policy resource is:

com.cloudflare.edge.r2.bucket.<ACCOUNT_ID>_<JURISDICTION>_<BUCKET_NAME>

There is no prefix dimension (unlike AWS S3 IAM, where arn:aws:s3:::bucket/prefix/* works). So under a shared bucket, "one token per repo" is meaningless — every token reads and writes the whole bucket, and one leaked credential or fork-context injection reaches every participating repository. That is precisely the blast radius this design otherwise avoids, so sharing a bucket cannot be made safe by adding tokens.

Bucket count is not a constraint (limit 1,000,000) and KB-scale state is free either way, so per-repo buckets buy real isolation at zero cost.

What changed:

• Bucket name is derived: loop-state-<repo>, from GITHUB_REPOSITORY in CI and from package.json locally. A sibling repository gets its own bucket with no code change. R2_BUCKET still overrides.
• R2_PREFIX drops the now-redundant repo segment — state/ instead of state/tiny-oss/ — since the bucket name already carries the identity. Remote keys now mirror the local layout one-to-one.
• R2_BUCKET no longer has to be configured; unset expands to an empty string, which falls through to the derivation.
• README documents per-repo setup plus the onboarding steps for an additional repository.

For tiny-oss this means the bucket is loop-state-tiny-oss, not the loop-state-alex1990 named in my earlier comment. Nothing has been seeded yet, so there is no data to migrate — if that bucket was already created, delete it and create loop-state-tiny-oss with a token scoped to it alone.

Verified: derivation yields loop-state-tiny-oss for GITHUB_REPOSITORY=Alex1990/tiny-oss, loop-state-other-pkg for a sibling, the same value locally via package.json, honours a R2_BUCKET override, and unset-in-Actions (empty string) correctly falls through.

[Alex1990]

Correction: bucket name includes the owner — loop-state-alex1990-tiny-oss

Supersedes the bucket name in my previous comment (8eb59fd → ba06f30).

Bucket names are a flat, account-wide namespace, so deriving loop-state-<repo> meant two same-named repositories under different GitHub organisations (or accounts) would resolve to the same bucket — and since an R2 token can only be scoped to a bucket, that is a collision an attacker or a future reorganisation could walk into. The name is now loop-state-<owner>-<repo>, moving the collision surface up to owner + repository.

• Owner comes from GITHUB_REPOSITORY in CI and package.json's repository locally. All npm forms resolve identically — object {url}, string shorthand owner/repo, github:owner/repo, SSH and https (with or without .git). The string repository form was previously unhandled and would have failed; now covered.
• Names are normalised to R2's rules (lowercase, [a-z0-9-], no leading/trailing hyphen, 3–63 chars). owner-repo longer than 63 falls back to a stable content hash, since GitHub permits repository names up to 100 characters — truncated-but-stable, so the same repo always maps to the same bucket and different repos never collide.

Verified: Alex1990/tiny-oss → loop-state-alex1990-tiny-oss; Acme-Corp/tiny-oss → loop-state-acme-corp-tiny-oss (the case this change exists for); ALEX1990/Tiny-OSS normalises to the same name as the canonical spelling; a 39+100-character owner/repo yields a valid 63-character name that is idempotent and collision-free. Local and CI derivations agree, which is what makes a local seed write to the same bucket the workflow reads.

So the bucket to create is loop-state-alex1990-tiny-oss, with the token scoped to it alone. Nothing has been seeded, so there is still no data to migrate.

[Alex1990]

Commit prefixes corrected — this branch was force-pushed

Raised in review: 14 of the commits here were fix(loop): / refactor(loop): / docs(loop):, and loop-host work is repository maintenance — not a change a package consumer can observe.

Why it mattered more than wording. bumpp regenerates CHANGELOG.md from conventional commits, and I verified with a real changelogen --from v1.1.0 run that all 11 fix(loop): entries landed in the user-facing section:

### 🩹 Fixes
- **loop:** Log every decision that produces no run
- **loop:** Check out the PR's code for same-repo PRs
...
### 💅 Refactors
- **loop:** Derive one R2 bucket per repository

A user installing v1.2.0 would have read "Fixes: log every decision that produces no run" and concluded the package had been fixed. refactor is worse for versioning: changelogen carries it at semver: patch, so maintenance work would have driven release numbers. The repo's own convention already pointed the right way — ci: for CI (dab2f55), chore: for the loop host (da28a14).

All 16 commits are now chore(loop):. Re-running the changelog generator, the 💅 Refactors section disappears entirely and zero loop entries remain in Fixes.

New SHAs (the old ones referenced in my earlier comments are gone; f5562b0 was already correct and is unchanged):

Old	New	Subject
5958e68	5b91b9e	keep credential failures out of the human inbox
8eb59fd	0b820d5	derive one R2 bucket per repository
ba06f30	da8f781	include the owner in the derived bucket name
96b03c4	ce3fd02	shrink R2 configuration to three secrets
3c2bcc9	bc39614	repair workflow contexts that broke parsing
e0f7466	79c6241	let workflow_dispatch check out its own ref
45479f3	37e37fd	correct the model id, validate it, add a smoke

Verified the rewrite changed no content: git diff <old-HEAD> <new-HEAD> is empty — only messages moved.

The rule is now recorded (cd29dad)

AGENTS.md gains a Commit messages section: the type must describe what a consumer can observe. feat/fix/perf are for the published package, docs for user-facing docs, and chore(<area>) for anything no consumer sees — the loop host, CI, the norms layer, tooling — with an explicit note never to use fix/refactor for maintenance.

That keeps the package's own PR loop honest: when a loop run commits a real feature or fix it will use feat/fix, and when it touches its own host it will use chore(loop).

Lint, Test and loop are all green on the rewritten branch (17 commits).