chore(tasks): number and stack self-targeting task list - #11
Conversation
|
Warning Review limit reached
Next review available in: 56 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. 📝 WalkthroughWalkthroughAdded ChangesNightlight task roadmap
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@TASKS.md`:
- Around line 48-52: Add [stack: ...] annotations to the checkbox entries for
tasks `#7` and `#8` in TASKS.md, using the same named stack for task `#8` and its
dependency task `#5` so the dependency is represented; if stacking is not
appropriate, document an explicit exemption instead. Preserve the existing task
descriptions and prohibitions.
- Line 19: Update the supervised trial instructions in TASKS.md to require runs
covering two distinct stacks, using two explicit pnpm overnight invocations or
the documented multi-stack syntax. Specify the stack-notes handoff evidence that
must be checked for each stack, while retaining the --limit 2 requirement.
- Around line 21-24: Define the contract for `[/]` tasks before implementation:
specify how housekeeping extracts or stores the associated PR number, which
archive file receives merged tasks, and the exact archive entry format including
the task number, text, PR number, and human-step note. Also state whether and
how `tasksCompleted` and `tasksBlocked` in `docs/nightlight-meta.json` are
updated when a `[/]` task is archived.
- Around line 27-31: Persist whether the interrupted-task retry has already been
consumed, using durable branch or run metadata. Update the session-start orphan
scan to retry matching no-PR branches only when that marker is absent, record
the marker before retrying, and avoid further retries when it is present;
preserve the existing behavior for open PRs and clean orphaned branches.
- Around line 27-31: Update the orphaned-branch scan to query pull requests with
gh pr list --head using the matching task branch name, rather than performing a
repository-wide lookup. Treat matching branches with open or closed-but-unmerged
PRs as safe to leave untouched; only discard and retry branches whose matching
branch has no such PR.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: aca9fe89-fc50-4a26-97e8-993f8acd6e3c
📒 Files selected for processing (2)
TASKS.mddocs/nightlight-meta.json
|
|
||
| Acceptance criteria: per-task dispatch loop in `overnight.sh`; stack-notes created/appended per above; stacked-task prompts read from stack-notes, not raw diffs; housekeeping still runs once at the end of the full loop (optionally folding a completed stack's notes into that day's archive entry). | ||
|
|
||
| NEEDS HUMAN: before treating this as default, do a supervised trial run on a low-stakes repo — `--limit 2` across at least two different stacks (e.g. `pnpm overnight <repo> --limit 2 --stack <name>`) — confirming dispatch and stack-notes handoff work as intended. Don't skip this trial. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Make the supervised trial cover two stacks.
The requirement says “across at least two different stacks,” but the procedure shows one --stack <name> invocation. Define two explicit invocations or the supported multi-stack syntax. State the stack-notes evidence to verify. Otherwise, a one-stack run can satisfy the procedure without testing cross-stack handoff.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@TASKS.md` at line 19, Update the supervised trial instructions in TASKS.md to
require runs covering two distinct stacks, using two explicit pnpm overnight
invocations or the documented multi-stack syntax. Specify the stack-notes
handoff evidence that must be checked for each stack, while retaining the
--limit 2 requirement.
| - [ ] #9 [stack: core-loop] **Add TASKS.md status glyphs and auto-archive NEEDS HUMAN tasks on PR merge** | ||
| Right now blocked and NEEDS HUMAN tasks are only distinguishable by reading each line's free-text annotation, and NEEDS HUMAN tasks stay in TASKS.md indefinitely with no defined path back to archive once you've completed the manual step and merged the PR. Replace `- [ ]` with distinct glyphs written only by housekeeping (preserving its single-writer role): `[!]` for blocked, `[/]` for NEEDS HUMAN. Each housekeeping run also checks every `[/]`-annotated task's PR merge state (`gh pr view <PR> --json state,mergedAt`); if merged, archive it as completed (task number, text, PR number, note that it required a human step) and remove it from TASKS.md — no manual edit required from you beyond merging the PR. | ||
|
|
||
| Acceptance criteria: CLAUDE.md's "Section semantics" and "TASKS.md maintenance" sections document `[ ]`/`[!]`/`[/]` semantics; housekeeping sets `[!]`/`[/]` when annotating blocked/NEEDS HUMAN tasks; housekeeping checks merge state of every `[/]` task's PR each run and auto-archives any now-merged ones. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Define the [/] task PR and archive contract.
The task does not define where housekeeping gets <PR> from. It also does not define the archive file, entry format, or whether tasksCompleted and tasksBlocked in docs/nightlight-meta.json must change. Specify these contracts before implementation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@TASKS.md` around lines 21 - 24, Define the contract for `[/]` tasks before
implementation: specify how housekeeping extracts or stores the associated PR
number, which archive file receives merged tasks, and the exact archive entry
format including the task number, text, PR number, and human-step note. Also
state whether and how `tasksCompleted` and `tasksBlocked` in
`docs/nightlight-meta.json` are updated when a `[/]` task is archived.
| Once tasks run as separate subprocesses (see task #2), a session interrupted mid-task (window closed, machine slept) needs to be detected on the next run without writing anything to TASKS.md mid-session, since only housekeeping may write there. Give each task branch's first commit a `Task: #<n>` trailer. At the start of a session, scan local branches for that trailer against every currently-open (`[ ]`) task; if a matching branch exists with no open PR (`gh pr list`), housekeeping never ran for it — treat it as an interrupted attempt: discard the branch and retry the task once from a clean state, per task #1's retry-once rule. If a matching branch has an open PR, leave it alone; that's just "done, housekeeping hasn't run yet," not interrupted. | ||
|
|
||
| Note: this reuses task #1's retry-once behavior, which lives in a different (solo) stack. If #1 hasn't merged to main by the time this task is reached, treat that as a cross-stack dependency per existing rules (stop, annotate blocked, move on) rather than reimplementing the rule inline. | ||
|
|
||
| Acceptance criteria: task branches' first commit includes a `Task: #<n>` trailer; session start includes a scan step that identifies orphaned branches (matching trailer, no open PR) for open tasks; orphaned branches are discarded and their task retried once from a clean state; branches with an open PR are left untouched. Depends on task #2. |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift
Persist the one-retry budget.
A matching branch with no PR identifies an orphaned attempt, but it does not identify whether the allowed retry was already used. If the retry is interrupted before a PR opens, the next session will see the same condition and retry indefinitely. Store a durable retry marker in branch metadata or run metadata, and include it in the scan rules.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@TASKS.md` around lines 27 - 31, Persist whether the interrupted-task retry
has already been consumed, using durable branch or run metadata. Update the
session-start orphan scan to retry matching no-PR branches only when that marker
is absent, record the marker before retrying, and avoid further retries when it
is present; preserve the existing behavior for open PRs and clean orphaned
branches.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Files matching TASKS.md:\n'
fd -a '^TASKS\.md$' . || true
printf '\nRelevant TASKS.md lines:\n'
if [ -f TASKS.md ]; then
nl -ba TASKS.md | sed -n '1,80p'
else
TASK_FILE="$(fd '^TASKS\.md$' . | head -n1 || true)"
if [ -n "${TASK_FILE:-}" ]; then nl -ba "$TASK_FILE" | sed -n '1,80p'; fi
fi
printf '\nSearch for gh pr list / Task trailer / housekeeping terms:\n'
rg -n "gh pr list|Task: #|housekeeping|retry-once|interrupted|orphan|clean state" -S . || trueRepository: c0d3ster/nightlight
Length of output: 276
🌐 Web query:
GitHub CLI gh pr list head branch option state open closed merged
💡 Result:
The GitHub CLI (gh) command gh pr list provides options to filter pull requests by state and head branch, among other criteria [1][2]. State Filtering You can filter pull requests by their state using the --state flag [1]. The available states are open, closed, merged, or all [1][2]. By default, gh pr list only returns open pull requests [1][2]. Example: gh pr list --state merged Head Branch Filtering You can filter pull requests by the head branch name using the --head flag [1]. Usage: gh pr list --head "branch-name" Important considerations for the --head flag: - Syntax: It does not support the "owner:branch" (or "owner:ref") qualified syntax [1][3][4]. It expects only the branch name [1][4]. - Matching: The --head flag performs an exact match on the branch name [5]. Alternative Searching If you need more flexible matching (such as fuzzy matching or using the "owner:branch" syntax), you can use the --search flag to leverage GitHub's PR search query syntax [2][5]. Example: gh pr list --search "head:my-branch-name" For more advanced requirements, such as filtering for multiple branches or specific criteria not covered by these flags, you can retrieve the data in JSON format and filter it locally using tools like jq [1][5]: gh pr list --json number,headRefName --jq 'map(select(.headRefName == "branch-name"))'
Citations:
- 1: https://cli.github.com/manual/gh_pr_list
- 2: https://manpages.ubuntu.com/manpages/noble/man1/gh-pr-list.1.html
- 3:
gh pr list: no support for--head <owner>:<branch>syntax cli/cli#10945 - 4: Add example usage of
--headoption topr listdocs cli/cli#10979 - 5: PR search by multiple exact branch names cli/cli#10816
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'TASKS.md line 20-40:\n'
awk 'NR>=20 && NR<=40 {printf "%6d\t%s\n", NR, $0}' TASKS.md
printf '\nDetailed references to PR lookup and branch handling:\n'
grep -nE "gh pr list|Task: #[0-9]+|interrupted|housekeeping|retry-once|orphan|branch" TASKS.md || trueRepository: c0d3ster/nightlight
Length of output: 8572
Scope the PR lookup to the matching task branch.
gh pr list has no head-branch option; a bare query can map a matching branch to another work-in-progress PR and delete local task work. Use gh pr list --head <branch-name> for the matching task branch, and include closed but unmerged states as safe branches to leave alone before treating a branch as an orphaned interrupted attempt.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@TASKS.md` around lines 27 - 31, Update the orphaned-branch scan to query pull
requests with gh pr list --head using the matching task branch name, rather than
performing a repository-wide lookup. Treat matching branches with open or
closed-but-unmerged PRs as safe to leave untouched; only discard and retry
branches whose matching branch has no such PR.
| - [ ] #7 **Resolve whether nightlight needs npm/package distribution at all** | ||
| This blocks further naming work. nightlight is used only by us, across repos we own — it isn't something anyone else installs. Options on the table: skip packaging entirely and keep nightlight as files in a personal dotfiles-style repo (current de facto state); package it as a Claude Code plugin/skill for "install once, use everywhere" convenience across machines; or proceed with an npm package under a scoped name (`@c0d3ster/nightlight` or similar) despite the unscoped name being taken. Requires your input — not an agent judgment call. | ||
|
|
||
| - [ ] #8 **Decide whether to layer `--permission-mode auto` under the existing allowlist, or hold at `acceptEdits`** | ||
| Depends on the Verify task above confirming eligibility. If eligible, decide whether to add `auto` mode as an additional safety layer underneath the existing `.claude/settings.json` allow/deny list, or hold at current `acceptEdits` behavior. Note: do not adopt a `bypassPermissions`-style fallback under any circumstance — if `auto` isn't available, staying on `acceptEdits` plus the explicit list is the safer posture. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Add stack annotations to the Decision tasks.
The repository workflow contract requires every checkbox line to have a [stack: ...] annotation. Tasks #7 and #8 omit this annotation. Task #8 also depends on task #5, but task #5 is marked [stack: solo]; this does not encode the dependency. Add stack tags and use the same named stack for dependent tasks, or document an explicit exemption.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@TASKS.md` around lines 48 - 52, Add [stack: ...] annotations to the checkbox
entries for tasks `#7` and `#8` in TASKS.md, using the same named stack for task `#8`
and its dependency task `#5` so the dependency is represented; if stacking is not
appropriate, document an explicit exemption instead. Preserve the existing task
descriptions and prohibitions.
- #11 [stack: solo] Make DB schema/migration generation NEEDS HUMAN - Amend #2's NEEDS HUMAN trial to require a cache-read cost comparison against the 2026-08-06 baseline before adopting split-per-task as default - nextTaskNumber -> 12 (only #11 was formally assigned here; the out-of-band format-stream.jq log fix, PR #21, was never written into TASKS.md under a number, so it never consumed one) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- #11 [stack: solo] Make DB schema/migration generation NEEDS HUMAN - Amend #2's NEEDS HUMAN trial to require a cache-read cost comparison against the 2026-08-06 baseline before adopting split-per-task as default - nextTaskNumber -> 12 (only #11 was formally assigned here; the out-of-band format-stream.jq log fix, PR #21, was never written into TASKS.md under a number, so it never consumed one) Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
1 participant
Summary
#1-#10numbers and[stack: ...]annotations to every item in TASKS.md's Agent-Ready, Verify, Research, and Decisions sections (nightlight's own self-improvement backlog).docs/nightlight-meta.jsonwithnextTaskNumber: 11to track numbering going forward.--limit 2across multiple stacks).[!]/[/]+ auto-archive of NEEDS HUMAN tasks on PR merge) and fix(plan): support self-targeting nightlight's own TASKS.md #10 (interrupted-task detection via git branch scan + retry-once, reusing task chore: add MIT license, ignore node_modules, fix runner scripts #1's retry rule).Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit