35 lines
2.3 KiB
Markdown
35 lines
2.3 KiB
Markdown
|
# BUG_REPORT: add-loop-templates-onboarding
|
||
|
|
|
||
|
|
## Methodology
|
||
|
|
|
||
|
|
Adversarial review of all changed files. Searched for: race conditions, token injection, path traversal, missing error handling, backward compat breaks, and edge cases in prompt resolution.
|
||
|
|
|
||
|
|
## Findings
|
||
|
|
|
||
|
|
### Bug 1 (LOW): `_resolve_prompt` writes temp file even when no tokens are substituted
|
||
|
|
|
||
|
|
If a prompt file exists but contains no tokens (e.g. a static prompt), `_resolve_prompt` still reads it, does the substitution loop (which is a no-op), and writes a copy to `outputs/tickN-<role>-prompt.md`. This is wasteful but not incorrect -- the harness receives an identical prompt either way. The temp file provides an audit trail of what was sent to the harness, which is actually useful for debugging.
|
||
|
|
|
||
|
|
**Severity:** LOW (performance/ cleanliness, not correctness)
|
||
|
|
**Fix:** None needed for v1. The audit trail value outweighs the minor I/O cost.
|
||
|
|
|
||
|
|
### Bug 2 (LOW): No token for `{cwd}` in content-level substitution
|
||
|
|
|
||
|
|
The harness command template supports `{cwd}` as an argv-level token, but `_resolve_prompt` does not substitute `{cwd}` in the prompt file content. If a prompt author writes `{cwd}` in the prompt text, it will appear literally in the resolved prompt. The SPEC does not list `{cwd}` as a content-level token (R1 lists `{task_brief}`, `{acceptance_criteria}`, `{next_hint}`, `{current_task}`, `{current_phase}`, `{verdict}`, `{artifact_content}`), so this is by design -- `{cwd}` is a harness-command token, not a content-level token.
|
||
|
|
|
||
|
|
**Severity:** LOW (documentation, not a bug)
|
||
|
|
**Fix:** None needed. The prompt files use "Working directory: the cwd you were launched with" instead of `{cwd}`.
|
||
|
|
|
||
|
|
### Bug 3 (INFO): `loop-orchestrate.md` references `code_review:awaiting_approval` then `--approve` in one step
|
||
|
|
|
||
|
|
The orchestrate prompt says "If in `code_review`: transition to `code_review:awaiting_approval`, then approve." This is two `status.py` calls in one tick. The orchestrator role is a single LLM session that can make multiple CLI calls, so this is valid. The runner does not restrict the number of subprocess calls the orchestrator makes.
|
||
|
|
|
||
|
|
**Severity:** INFO (not a bug)
|
||
|
|
**Fix:** None needed.
|
||
|
|
|
||
|
|
## Summary
|
||
|
|
|
||
|
|
No correctness bugs found. Two LOW-severity observations and one INFO note. The implementation is solid for v1.
|
||
|
|
|
||
|
|
**Verdict: CLEAN**
|