Skip to content

feat(architect): two-phase read-only tool access (#193 PR 3)#196

Merged
Abernaughty merged 1 commit into
mainfrom
feat/issue-193-architect-tool-access
Apr 17, 2026
Merged

feat(architect): two-phase read-only tool access (#193 PR 3)#196
Abernaughty merged 1 commit into
mainfrom
feat/issue-193-architect-tool-access

Conversation

@Abernaughty

@Abernaughty Abernaughty commented Apr 17, 2026

Copy link
Copy Markdown
Owner

Summary

Third and final PR for #193 — gives the Architect optional read-only tool access via a two-phase flow:

  • Phase 1 (unchanged): no-tools LLM call; preserves existing cost profile for simple tasks.
  • Sufficiency gate (_blueprint_is_sufficient): rejects empty target_files, placeholder paths (path/to/..., angle brackets, TODO/TBD/unknown), and instructions shorter than 20 chars.
  • Phase 2 (new, conditional): binds READONLY_TOOLS (filesystem_list, filesystem_read, github_read_diff) via _run_tool_loop, capped at MAX_ARCHITECT_TOOL_TURNS (default 4), then reparses the Blueprint.
  • Fallback: if Phase 2 fails to parse, return the Phase 1 Blueprint so the outer retry loop can still make progress.
  • Phase 2 tool calls are logged under the architect agent in result["tool_calls_log"]; Phase 1 output is left untouched when sufficient.

This closes the last gap for the self-dev gate (#113): when the Planner pre-fetches a GitHub issue and hands it to the Architect, the Architect can now actually verify which files exist before emitting the Blueprint.

Test plan

  • New tests/test_architect_two_phase.py (16 tests, all pass):
    • 7 heuristic tests for _blueprint_is_sufficient
    • 6 behavioral tests (Phase 1 sufficient skips Phase 2; insufficient no-tools falls through; insufficient escalates; Phase 2 tool calls logged; Phase 1 unparseable → Phase 2 rescues; both fail → FAILED)
    • 1 max-turns test (Phase 2 exhausts turns → falls back to Phase 1 Blueprint with BUILDING status)
    • 2 integration tests simulating Fix-issue-bug: Terminal panel drag-to-resize breaks after ~1/3 screen height #113 flow with Planner-prefetched GitHub context
  • uv run ruff check src/ tests/ clean
  • Full regression suite: 1097 passed, 2 skipped, 1 pre-existing unrelated failure (test_workspace::test_from_env_defaults env-var leak)
  • CI green

Refs #193

🤖 Generated with Claude Code

Add optional Phase 2 tool loop for the Architect when Phase 1 output
is insufficient. Phase 1 preserves existing no-tools behavior; Phase 2
binds READONLY_TOOLS (filesystem_list/read, github_read_diff) via
_run_tool_loop, capped at MAX_ARCHITECT_TOOL_TURNS (default 4), then
reparses the Blueprint. On Phase 2 parse failure, falls back to the
Phase 1 Blueprint so the retry loop can still make progress.

Sufficiency gate (_blueprint_is_sufficient) rejects empty target_files,
placeholder paths ("path/to/...", angle-bracketed, TODO/TBD/unknown),
and overly short instructions (<20 chars).

New tests (16) cover sufficiency heuristics, both-phase behavior, max-
turn exhaustion, and a Fix-issue-#113 integration flow that exercises
Planner-prefetched issue context through the two-phase architect.

Refs #193

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@Abernaughty Abernaughty merged commit 2ebec51 into main Apr 17, 2026
3 checks passed
@Abernaughty Abernaughty deleted the feat/issue-193-architect-tool-access branch April 17, 2026 20:41
Abernaughty added a commit that referenced this pull request Apr 17, 2026
… (refs #193)

The Planner's system prompt unconditionally declared "ZERO tool access",
causing the LLM to tell users it could not look up GitHub issues even
when PR #195's deterministic pre-fetch had already injected the issue
body as a secondary system message. Users reported the bug with "Review
and implement the fix for GitHub Issue #113" — the Planner replied
"I don't have access to GitHub" despite the issue content being in its
context window.

Changes:
- _PLANNER_SYSTEM_PROMPT now explains the pre-fetch flow and explicitly
  forbids denying GitHub access when the PRE-FETCHED GITHUB CONTEXT
  block is present.
- _format_github_context_block wraps the payload in clear start/end
  markers that the system prompt references by name.
- _prefetch_github_refs_for_message logs a warning (not silent skip)
  when refs were detected but GITHUB_TOKEN is missing or the fetch
  returned zero items, so operators can diagnose environment issues.
- Four new tests in TestPlannerSystemPromptReconciliation cover: the
  system prompt no longer contains "ZERO tool access", the context
  block carries start/end markers, empty inputs produce no block, and
  the new warning log fires when refs are detected without a token.

Closes the AC #3 gap in issue #193 (Planner "fetches" GitHub issues
when referenced). All other ACs were already satisfied by PRs #194-#196.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Abernaughty added a commit that referenced this pull request Apr 17, 2026
… (refs #193) (#197)

The Planner's system prompt unconditionally declared "ZERO tool access",
causing the LLM to tell users it could not look up GitHub issues even
when PR #195's deterministic pre-fetch had already injected the issue
body as a secondary system message. Users reported the bug with "Review
and implement the fix for GitHub Issue #113" — the Planner replied
"I don't have access to GitHub" despite the issue content being in its
context window.

Changes:
- _PLANNER_SYSTEM_PROMPT now explains the pre-fetch flow and explicitly
  forbids denying GitHub access when the PRE-FETCHED GITHUB CONTEXT
  block is present.
- _format_github_context_block wraps the payload in clear start/end
  markers that the system prompt references by name.
- _prefetch_github_refs_for_message logs a warning (not silent skip)
  when refs were detected but GITHUB_TOKEN is missing or the fetch
  returned zero items, so operators can diagnose environment issues.
- Four new tests in TestPlannerSystemPromptReconciliation cover: the
  system prompt no longer contains "ZERO tool access", the context
  block carries start/end markers, empty inputs produce no block, and
  the new warning log fires when refs are detected without a token.

Closes the AC #3 gap in issue #193 (Planner "fetches" GitHub issues
when referenced). All other ACs were already satisfied by PRs #194-#196.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant