chore: remove IDE and agent_loop dirs from git tracking
This commit is contained in:
+8
-3
@@ -29,10 +29,15 @@ npm-debug.log*
|
||||
next-env.d.ts
|
||||
.aider*
|
||||
|
||||
# editor / agent tooling
|
||||
.claude/
|
||||
.idea/
|
||||
.zed/
|
||||
|
||||
# agent loop
|
||||
agent_loop/
|
||||
|
||||
# agent loop generated output
|
||||
agent_loop/logs/
|
||||
agent_loop/runs/
|
||||
agent_loop/__pycache__/
|
||||
logs/
|
||||
runs/
|
||||
|
||||
|
||||
Generated
-10
@@ -1,10 +0,0 @@
|
||||
# Default ignored files
|
||||
/shelf/
|
||||
/workspace.xml
|
||||
# Editor-based HTTP Client requests
|
||||
/httpRequests/
|
||||
# Ignored default folder with query files
|
||||
/queries/
|
||||
# Datasource local storage ignored files
|
||||
/dataSources/
|
||||
/dataSources.local.xml
|
||||
Generated
-8
@@ -1,8 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<project version="4">
|
||||
<component name="ProjectModuleManager">
|
||||
<modules>
|
||||
<module fileurl="file://$PROJECT_DIR$/.idea/TimeToLeave.iml" filepath="$PROJECT_DIR$/.idea/TimeToLeave.iml" />
|
||||
</modules>
|
||||
</component>
|
||||
</project>
|
||||
Generated
-8
@@ -1,8 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<module type="WEB_MODULE" version="4">
|
||||
<component name="NewModuleRootManager">
|
||||
<content url="file://$MODULE_DIR$" />
|
||||
<orderEntry type="inheritedJdk" />
|
||||
<orderEntry type="sourceFolder" forTests="false" />
|
||||
</component>
|
||||
</module>
|
||||
Generated
-6
@@ -1,6 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="VcsDirectoryMappings">
|
||||
<mapping directory="$PROJECT_DIR$/oebb-planner-app" vcs="Git" />
|
||||
</component>
|
||||
</project>
|
||||
@@ -1,77 +0,0 @@
|
||||
# Review Agent Rules
|
||||
|
||||
These rules apply when reviewing completed implementation steps on the `rewrite/next` branch.
|
||||
|
||||
## Checklist Tracking
|
||||
|
||||
`CHECKLIST.md` uses three checkbox states:
|
||||
- `[ ]` — pending and **required**; blocks the next phase
|
||||
- `[x]` — done
|
||||
- `[~]` — optional or deferred; **never blocks phase advancement**
|
||||
|
||||
Rules:
|
||||
- The ✅ column belongs to the rewrite agent; the ✔️ column is yours.
|
||||
- Only review items whose ✅ box is already `[x]`. Do not attempt to review unimplemented items.
|
||||
- If a ✅ box is `[~]` (optional, skipped), mark the ✔️ box `[~]` as well — no review needed for skipped items.
|
||||
- After reviewing each required item and confirming it meets the quality bar below, mark its ✔️ box by changing `[ ]` to `[x]`.
|
||||
- Before reviewing any item in a new phase, read `CHECKLIST.md` and confirm that every **required** item in all preceding phases has `[x]` in both ✅ and ✔️. Items where both columns are `[~]` do not need review and do not block advancement.
|
||||
- If any required box in a previous phase is unchecked, stop and report which items are blocking progress instead of proceeding.
|
||||
|
||||
## Review Scope
|
||||
|
||||
- Review one phase at a time. Within a phase, review items in the order they appear in `CHECKLIST.md`.
|
||||
- For each item, cross-reference the implementation against `REWRITE_PLAN.md` and the quality criteria below.
|
||||
- Report concrete issues with file paths and line numbers. Do not flag style nitpicks that are not covered by a project guideline.
|
||||
|
||||
## What to Check
|
||||
|
||||
**Correctness**
|
||||
- The behavior matches the intent described in `REWRITE_PLAN.md` and the checklist item.
|
||||
- API contracts, endpoint shapes, and TypeScript types are compatible with existing callers.
|
||||
- No regressions are introduced in previously working behavior.
|
||||
|
||||
**Tests**
|
||||
- Tests exist for the new code and cover the main success path, edge cases, and failure behavior.
|
||||
- Tests are not weakened or removed just to make the suite pass.
|
||||
- External services (HAFAS, Nominatim, OSRM, geolocation, time, calendar downloads) are mocked; tests do not depend on live network availability.
|
||||
|
||||
**Quality**
|
||||
- No compile errors, lint errors, runtime crashes, or broken imports.
|
||||
- TypeScript strictness is intact — no `any` used as a shortcut.
|
||||
- Server-only code is not imported into client components.
|
||||
- Nominatim usage follows the project requirements: configurable base URL, clear user agent, rate-limit-aware caching, no direct browser calls.
|
||||
- Error handling is explicit and user-facing failures are understandable.
|
||||
- No generated artifacts, caches, logs, or local environment files are committed.
|
||||
- Dependencies are unchanged unless necessary and justified.
|
||||
|
||||
**Scope**
|
||||
- The change is scoped to the checklist item — no unrelated modifications.
|
||||
- Old implementation files (`server/`, `oebb-planner-app/`, `oebb-planner.jsx`) were not removed unless parity is tested and cleanup was explicitly requested.
|
||||
|
||||
**Accessibility (UI items only)**
|
||||
- Semantic buttons and links, labels for inputs, keyboard-operable controls, visible loading and error states.
|
||||
|
||||
## Verification
|
||||
|
||||
- Run the relevant test and build checks to confirm the implementation passes before marking ✔️:
|
||||
|
||||
```bash
|
||||
npm test
|
||||
npm run build
|
||||
npm run typecheck
|
||||
npm run lint
|
||||
```
|
||||
|
||||
- If a check fails, do not mark the ✔️ box. Report the failure with the exact output and leave the item for the rewrite agent to fix.
|
||||
|
||||
## Completion Checklist
|
||||
|
||||
Before marking a ✔️ box, confirm:
|
||||
|
||||
- The ✅ box for this item is already checked by the rewrite agent.
|
||||
- All preceding phase items have both ✅ and ✔️ checked.
|
||||
- The implementation matches the intent in `REWRITE_PLAN.md`.
|
||||
- Tests exist, are meaningful, and pass.
|
||||
- Build and type checks pass.
|
||||
- No quality issues from the criteria above remain unresolved.
|
||||
- Any limitations or known gaps are reported clearly to the user.
|
||||
@@ -1,114 +0,0 @@
|
||||
# Rewrite Agent Rules
|
||||
|
||||
These rules apply when implementing the Next.js rewrite on the `rewrite/next` branch.
|
||||
|
||||
## Checklist Tracking
|
||||
|
||||
`CHECKLIST.md` uses three checkbox states:
|
||||
- `[ ]` — pending and **required**; blocks the next phase
|
||||
- `[x]` — done
|
||||
- `[~]` — optional or deferred; **never blocks phase advancement**
|
||||
|
||||
Rules:
|
||||
- The ✅ column is yours; the ✔️ column belongs to the review agent.
|
||||
- After completing each numbered item, mark its ✅ box by changing `[ ]` to `[x]`.
|
||||
- If you complete an optional item (`[~]`), change it to `[x]`. If you skip it, leave it as `[~]`.
|
||||
- Before starting any item in a new phase, read `CHECKLIST.md` and confirm that every **required** (`[ ]`/`[x]`) item in all preceding phases has `[x]` in both ✅ and ✔️. Items marked `[~]` in both columns do not need to be completed first.
|
||||
- If any required box in a previous phase is unchecked, stop and report which items are blocking progress instead of proceeding.
|
||||
|
||||
## Rewrite Context
|
||||
|
||||
- `REWRITE_PLAN.md` is the guiding plan for the migration from the current CRA + Express app to a Next.js App Router + TypeScript app.
|
||||
- When working on the rewrite, follow the migration phases in `REWRITE_PLAN.md` unless the user explicitly asks for a different order.
|
||||
- Treat each numbered migration item as a checkpoint: implement it, update its ✅ box in `CHECKLIST.md`, add or update tests, run the relevant verification, then continue.
|
||||
- Prefer building the new Next.js structure in parallel until feature parity is proven. Do not delete `server/`, `oebb-planner-app/`, or `oebb-planner.jsx` before equivalent Next.js behavior is implemented, tested, and the user has clearly asked for cleanup.
|
||||
- Preserve existing API contracts and user-visible behavior during migration unless the rewrite plan or user request explicitly changes them.
|
||||
- Use `npm` consistently because the existing project uses `package-lock.json`.
|
||||
|
||||
## Work Step By Step
|
||||
|
||||
- Start by reading the relevant files and identifying the smallest safe next step.
|
||||
- State the plan before making non-trivial changes.
|
||||
- Implement one coherent change at a time.
|
||||
- After each step, review the diff and check whether it still matches the intended behavior.
|
||||
- Do not move on to the next step while the current step has unresolved compile errors, failing tests, or obvious regressions.
|
||||
- Prefer small, targeted edits over broad rewrites.
|
||||
- Preserve existing behavior unless the user explicitly asks to change it.
|
||||
- When a task spans multiple rewrite phases, complete one vertical slice at a time where practical: type or library code, route or hook, UI integration, tests, then verification.
|
||||
- Keep reusable logic in `src/lib`, side effects in hooks or route handlers, and shared contracts in `src/types`.
|
||||
|
||||
## Testing Requirements
|
||||
|
||||
- Add or update tests for every new feature, bug fix, and behavior change.
|
||||
- Put tests near the code they cover and follow the existing test style.
|
||||
- Cover the main success path, important edge cases, and failure behavior.
|
||||
- Do not remove or weaken tests just to make the suite pass.
|
||||
- If a change cannot reasonably be tested, explain why and add the closest practical verification.
|
||||
- For the Next.js rewrite, prefer unit tests for `src/lib`, route tests for `src/app/api`, and component smoke or behavior tests for UI components.
|
||||
- Mock external services in automated tests, including ÖBB HAFAS, Nominatim, OSRM, geolocation, time, and calendar downloads. Do not make tests depend on live network availability.
|
||||
- Test TypeScript data shapes and boundary parsing where API responses are transformed into app types.
|
||||
|
||||
## Verification Before Moving On
|
||||
|
||||
- Run the narrowest relevant tests after each meaningful change.
|
||||
- Run the broader project checks before finishing.
|
||||
- For server changes, run:
|
||||
|
||||
```bash
|
||||
cd server
|
||||
npm test
|
||||
```
|
||||
|
||||
- For React app changes, run:
|
||||
|
||||
```bash
|
||||
cd oebb-planner-app
|
||||
CI=true npm test -- --watchAll=false
|
||||
npm run build
|
||||
```
|
||||
|
||||
- For the Next.js rewrite, once the root Next.js project exists, run the relevant root checks instead:
|
||||
|
||||
```bash
|
||||
npm test
|
||||
npm run build
|
||||
```
|
||||
|
||||
- If available, also run type-checking and linting scripts before finishing:
|
||||
|
||||
```bash
|
||||
npm run typecheck
|
||||
npm run lint
|
||||
```
|
||||
|
||||
- If a change touches both server and app behavior, run both sets of checks.
|
||||
- If a command fails, stop, inspect the failure, fix the cause, and rerun the command.
|
||||
- Do not claim the work is complete until the relevant checks pass, or until the remaining blocker is clearly reported.
|
||||
|
||||
## Quality Bar
|
||||
|
||||
- Make sure additions do not introduce compile errors, lint errors, runtime crashes, or broken imports.
|
||||
- Check that public APIs, endpoint contracts, props, and data shapes remain compatible with existing callers.
|
||||
- Keep error handling explicit and user-facing failures understandable.
|
||||
- Avoid hidden global state, timing assumptions, and network-dependent tests unless the project already uses that pattern.
|
||||
- Keep dependencies unchanged unless they are necessary for the task and justified.
|
||||
- Do not commit generated artifacts, caches, logs, or local environment files.
|
||||
- Keep TypeScript strictness intact once introduced. Do not use `any` as a shortcut around unclear domain types.
|
||||
- Keep server-only code out of client components. Route handlers and `src/lib` clients that use secrets, privileged headers, or upstream service details must not be imported into browser-only code.
|
||||
- Respect Nominatim usage requirements when implementing geocoding: configurable base URL, clear user agent, rate-limit-aware caching, and no direct browser calls to the public service.
|
||||
- Keep OSRM and HAFAS clients behind API routes or server-side utilities so failures can be normalized and tested.
|
||||
- For UI work, preserve accessibility basics: semantic buttons and links, labels for inputs, keyboard-operable controls, visible loading and error states.
|
||||
|
||||
## Completion Checklist
|
||||
|
||||
Before finishing a step, confirm:
|
||||
|
||||
- The requested behavior is implemented.
|
||||
- The ✅ box for the corresponding item in `CHECKLIST.md` is checked.
|
||||
- The change matches the relevant phase or numbered item in `REWRITE_PLAN.md`, when applicable.
|
||||
- Tests were added or updated where appropriate.
|
||||
- Relevant tests and build checks pass.
|
||||
- The change is scoped to the request.
|
||||
- No unrelated user changes were overwritten.
|
||||
- Old implementation files were not removed unless parity is tested and cleanup was requested.
|
||||
- Any limitations or skipped checks are reported clearly.
|
||||
@@ -1,5 +0,0 @@
|
||||
// Folder-specific settings
|
||||
//
|
||||
// For a full list of overridable settings, and general information on folder-specific settings,
|
||||
// see the documentation: https://zed.dev/docs/configuring-zed#settings-files
|
||||
{}
|
||||
@@ -1,15 +0,0 @@
|
||||
[
|
||||
{
|
||||
"label": "Run Wiener Linien agent loop",
|
||||
"command": "python",
|
||||
"args": [
|
||||
"ttl_agent_gemma4.py",
|
||||
"--workspace", "/home/fegger/Code/TimeToLeave",
|
||||
"--run-until-done"
|
||||
],
|
||||
"cwd": "$ZED_WORKTREE_ROOT/agent_loop",
|
||||
"use_new_terminal": true,
|
||||
"allow_concurrent_runs": false,
|
||||
"reveal": "always"
|
||||
}
|
||||
]
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,179 +0,0 @@
|
||||
from agent_base import main
|
||||
|
||||
WRITER_PROMPT = """You are a disciplined TypeScript software engineering agent implementing the Wiener Linien feature on the TimeToLeave project.
|
||||
|
||||
## Checklist Tracking
|
||||
|
||||
`CHECKLIST.md` uses three checkbox states:
|
||||
- `[ ]` — pending and required; blocks the next step
|
||||
- `[x]` — done
|
||||
- `[~]` — optional or deferred; never blocks advancement
|
||||
|
||||
Rules:
|
||||
- The ✅ column is yours; the ✔️ column belongs to the review agent.
|
||||
- Before starting, read `CHECKLIST.md` and find the first step where ✅ is `[ ]`.
|
||||
- Confirm that every preceding step has both ✅ and ✔️ as `[x]`. If not, stop and report which steps are blocking — do not proceed.
|
||||
- Implement only that one step. Do not implement any later steps.
|
||||
- After completing the step, mark its ✅ box by changing `[ ]` to `[x]` in `CHECKLIST.md` and include the updated file in your `files` array.
|
||||
- Do not mark the ✔️ column — that belongs to the review agent.
|
||||
|
||||
## Project Context
|
||||
|
||||
Project root: files are specified as paths relative to the project root (e.g. `src/types/index.ts`).
|
||||
Stack: Next.js 16 App Router, React 19, TypeScript strict mode, Tailwind CSS v4, Vitest.
|
||||
Feature: Wiener Linien real-time departures via the free OGD Echtzeitdaten REST API (`https://www.wienerlinien.at/ogd_realtime`).
|
||||
Architecture pattern: `src/lib` clients → `src/app/api` proxy routes → `src/hooks` hooks → UI components in `src/app`.
|
||||
|
||||
## Work Step By Step
|
||||
|
||||
- Start by reading `CHECKLIST.md` to identify the current step, then read the relevant existing files.
|
||||
- State what the current step requires before making changes.
|
||||
- Implement one coherent change at a time. Prefer small targeted edits over rewrites.
|
||||
- Review the diff mentally before submitting — ensure it matches the intended behavior.
|
||||
- Do not move to the next step. The review agent must mark ✔️ before the next step begins.
|
||||
|
||||
## Quality Bar
|
||||
|
||||
- Patch the existing project; do not restart from scratch unless the file does not yet exist.
|
||||
- Use relative file paths only.
|
||||
- Return full file contents — no partial diffs or placeholders.
|
||||
- Keep TypeScript strictness intact. Never use `any`; use `unknown` at JSON/API boundaries with explicit type guards.
|
||||
- Prefer `const` over `let`; never use `var`.
|
||||
- Use async/await throughout; never mix Promise chains and callbacks.
|
||||
- Use `import type` for type-only imports.
|
||||
- Use named exports; avoid default exports in library code.
|
||||
- Keep server-only code out of client components. API calls to Wiener Linien must go through proxy routes, not directly from the browser.
|
||||
- Preserve existing working behavior unless the current step explicitly changes it.
|
||||
- For UI work: semantic elements, labels for inputs, keyboard-operable controls, visible loading and error states.
|
||||
- If you cannot produce a valid response matching the schema, emit: {"summary":"generation failed","files":[],"tests":[],"notes":["Internal error — retry."]}
|
||||
- Return only JSON matching the writer schema.
|
||||
"""
|
||||
|
||||
REVIEWER_PROMPT = """<|think|>
|
||||
You are a strict senior TypeScript reviewer embedded in a code-generation loop for the TimeToLeave project.
|
||||
|
||||
## Checklist Tracking
|
||||
|
||||
`CHECKLIST.md` uses three checkbox states:
|
||||
- `[ ]` — pending and required; blocks the next step
|
||||
- `[x]` — done
|
||||
- `[~]` — optional or deferred; never blocks advancement
|
||||
|
||||
Rules:
|
||||
- The ✔️ column is yours; the ✅ column belongs to the writing agent.
|
||||
- Only review steps whose ✅ box is already `[x]`. Do not attempt to review unimplemented steps.
|
||||
- Before reviewing, confirm that all preceding steps have both ✅ and ✔️ as `[x]`. If not, stop and report which steps are blocking.
|
||||
- If the step passes the quality bar below, set verdict to "approve". The orchestrator will mark ✔️ automatically.
|
||||
- If issues remain, set verdict to "needs_changes". Report the failures with file paths and line numbers.
|
||||
|
||||
## Review Scope
|
||||
|
||||
- Review one step at a time in the order steps appear in `CHECKLIST.md`.
|
||||
- Cross-reference the implementation against the step description in `CHECKLIST.md`.
|
||||
- Report concrete issues with file paths and line numbers. Do not flag style nitpicks not covered by a project guideline.
|
||||
|
||||
## What to Check
|
||||
|
||||
**Correctness**
|
||||
- Behavior matches the intent described in the CHECKLIST step.
|
||||
- API contracts, endpoint shapes, and TypeScript types are compatible with existing callers.
|
||||
- No regressions in previously working behavior.
|
||||
|
||||
**Tests**
|
||||
- Tests exist for new code covering the main success path, edge cases, and failure behavior.
|
||||
- Tests are not weakened or removed just to make the suite pass.
|
||||
- External services (Wiener Linien API, geolocation, time) are mocked; tests do not depend on live network availability.
|
||||
|
||||
**Quality**
|
||||
- No compile errors, lint errors, runtime crashes, or broken imports.
|
||||
- TypeScript strictness is intact — no `any` used as a shortcut.
|
||||
- Server-only code is not imported into client components.
|
||||
- Wiener Linien API calls go through proxy routes, not directly from the browser.
|
||||
- Error handling is explicit; user-facing failures are understandable.
|
||||
- No generated artifacts, caches, logs, or local environment files are committed.
|
||||
- Dependencies unchanged unless necessary and justified.
|
||||
|
||||
**Scope**
|
||||
- The change is scoped to the current CHECKLIST step — no unrelated modifications.
|
||||
|
||||
**Accessibility (UI steps only)**
|
||||
- Semantic elements, labels for inputs, keyboard-operable controls, visible loading and error states.
|
||||
|
||||
## Verification
|
||||
|
||||
Confirm that these checks would pass before setting verdict to "approve":
|
||||
|
||||
```bash
|
||||
npm test
|
||||
npm run build
|
||||
npm run typecheck
|
||||
npm run lint
|
||||
```
|
||||
|
||||
If any check would fail, set verdict to "needs_changes", report the failure with exact details, and leave the step for the writing agent to fix.
|
||||
|
||||
## Review priorities
|
||||
|
||||
1. build-breaking defects
|
||||
2. test-breaking defects
|
||||
3. runtime-breaking defects
|
||||
4. mismatch with the CHECKLIST step intent
|
||||
5. missing files, exports, wiring, or integration
|
||||
6. unsafe behavior
|
||||
7. incorrect types, null handling, async handling, state management
|
||||
8. missing edge-case handling
|
||||
9. important but non-blocking maintainability issues
|
||||
|
||||
Output field guidance:
|
||||
- critical_issues: only issues that break build, tests, or runtime
|
||||
- important_improvements: significant but not immediately blocking issues
|
||||
- preserve: list anything in the draft that is correct and must not be changed
|
||||
- rewrite_strategy: concrete alternative approaches the writer should try for unfixed critical issues
|
||||
- missing_files: files required by the CHECKLIST step that are absent
|
||||
- test_gaps: risky behavior with materially missing test coverage
|
||||
- file_comments: specific, actionable guidance tied to a file path
|
||||
|
||||
Rules:
|
||||
- Be concrete and rewrite-oriented.
|
||||
- Prefer issues the writer can directly fix in the next pass.
|
||||
- Do not ask questions.
|
||||
- Do not praise unless identifying something that must be preserved.
|
||||
- Assume the writer should patch the current code, not restart from scratch.
|
||||
- If the draft appears unchanged from a previous attempt for a given issue, escalate that issue to critical and suggest an alternative implementation approach.
|
||||
- If you have already flagged an issue and it was not fixed, say specifically what is still wrong and why the previous attempt failed.
|
||||
- Return only JSON matching the review schema.
|
||||
"""
|
||||
|
||||
DESIGN_PROMPT = """<|think|>
|
||||
You are a disciplined TypeScript architect working inside a coding loop on the TimeToLeave project.
|
||||
|
||||
Your job is to produce a concise implementation design for the current CHECKLIST step before coding begins.
|
||||
|
||||
Project context:
|
||||
- Next.js 16 App Router, React 19, TypeScript strict mode, Tailwind CSS v4, Vitest
|
||||
- Architecture: `src/lib` clients → `src/app/api` proxy routes → `src/hooks` hooks → `src/app` components
|
||||
- Feature: Wiener Linien real-time departures via `https://www.wienerlinien.at/ogd_realtime`
|
||||
- Read `CHECKLIST.md` to determine which step is being designed
|
||||
|
||||
Design priorities:
|
||||
1. file layout — which files to create or modify, and why
|
||||
2. responsibilities — what each file owns
|
||||
3. interfaces — types and function signatures
|
||||
4. integration points — how this step connects to existing code
|
||||
5. dependencies — imports from existing modules
|
||||
6. testing plan — what to test and how to mock
|
||||
7. risks — anything that could break existing behavior
|
||||
8. assumptions — things taken as given
|
||||
|
||||
Rules:
|
||||
- Optimize for patching an existing codebase; prefer minimal file churn.
|
||||
- Identify any conflicts with existing code (naming, module structure, API contracts).
|
||||
- Flag required structural changes separately from new additions.
|
||||
- If the step can be completed by modifying a single existing file, say so explicitly rather than proposing new files.
|
||||
- Do not redesign the whole project unless the step requires it.
|
||||
- Keep the design concrete and implementation-ready.
|
||||
- Return only JSON matching the design schema.
|
||||
"""
|
||||
|
||||
if __name__ == "__main__":
|
||||
raise SystemExit(main("TS", WRITER_PROMPT, REVIEWER_PROMPT, DESIGN_PROMPT))
|
||||
@@ -1,298 +0,0 @@
|
||||
import os
|
||||
from pathlib import Path
|
||||
|
||||
# Default workspace to the project root (parent of this script's agent_loop/ dir)
|
||||
# so the script works without --workspace when run from anywhere.
|
||||
os.environ.setdefault("AGENT_WORKSPACE", str(Path(__file__).resolve().parent.parent))
|
||||
os.environ.setdefault("AGENT_TASK", "Implement the next pending step in CHECKLIST.md")
|
||||
os.environ.setdefault("OLLAMA_API_BASE", "http://100.103.83.12:11435")
|
||||
os.environ.setdefault("WRITER_MODEL", "qwen3.6:27b-64k")
|
||||
os.environ.setdefault("REVIEWER_MODEL", "qwen3.6:27b-64k")
|
||||
os.environ.setdefault("DESIGN_MODEL", "qwen3.6:27b-64k")
|
||||
os.environ.setdefault("AGENT_MAX_REVIEW_LOOPS", "12")
|
||||
|
||||
from agent_base_gemma4 import main
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# TimeToLeave — project-specific agent
|
||||
#
|
||||
# Stack: Next.js 16 App Router · React 19 · TypeScript strict · Tailwind v4 · Vitest
|
||||
# Run: python ttl_agent_gemma4.py --task "..." --workspace <project-root> --write-to-workspace
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
WRITER_PROMPT = """You are a software engineering agent implementing features on the TimeToLeave project.
|
||||
|
||||
## FILE EXTENSION RULE — CHECK EVERY FILE BEFORE SUBMITTING
|
||||
|
||||
- `.tsx` — any file that contains JSX (`<Tag />`, `<div>`, `return (...)` with markup)
|
||||
- `.ts` — everything else: hooks, clients, routes, types, utilities
|
||||
|
||||
Examples:
|
||||
src/app/event/WienerLinienSection.tsx ← renders JSX → .tsx
|
||||
src/hooks/useWienerLinien.ts ← no JSX → .ts
|
||||
src/lib/wienerlinien-client.ts ← no JSX → .ts
|
||||
src/app/api/wienerlinien/stops/route.ts← no JSX → .ts
|
||||
|
||||
Wrong extension = broken build. Verify each path ends in the correct suffix.
|
||||
|
||||
## Checklist Tracking
|
||||
|
||||
`CHECKLIST.md` uses three checkbox states:
|
||||
- `[ ]` — pending and required; blocks the next step
|
||||
- `[x]` — done
|
||||
- `[~]` — optional or deferred; never blocks advancement
|
||||
|
||||
Rules:
|
||||
- The ✅ column is yours; the ✔️ column belongs to the review agent.
|
||||
- Before starting, read `CHECKLIST.md` and find the first step where ✅ is `[ ]`.
|
||||
- Confirm that every preceding step has both ✅ and ✔️ as `[x]`. If not, stop and report which steps are blocking — do not proceed.
|
||||
- Implement only that one step. Do not implement any later steps.
|
||||
- After completing the step, change its ✅ from `[ ]` to `[x]` in `CHECKLIST.md` and include the updated file in your `files` array.
|
||||
- Do not mark the ✔️ column — that belongs to the review agent.
|
||||
|
||||
## Stack
|
||||
|
||||
Next.js 16 App Router · React 19 · TypeScript strict · Tailwind CSS v4 · Vitest
|
||||
|
||||
**CRITICAL:** This Next.js version has breaking changes. Before using any Next.js API (routing,
|
||||
metadata, image, font, caching), read the relevant guide in `node_modules/next/dist/docs/`.
|
||||
Heed all deprecation notices. APIs and file conventions may differ from your training data.
|
||||
|
||||
## Architecture — Four Layers
|
||||
|
||||
Always follow this pattern:
|
||||
|
||||
src/lib/<name>-client.ts ← singleton, calls external API, server-only
|
||||
src/app/api/<name>/route.ts ← proxy: validates input, calls client, returns NextResponse
|
||||
src/hooks/use<Name>.ts ← hook: calls proxy route, manages loading/error/data
|
||||
src/app/**/<Name>Section.tsx ← component: receives props or calls hook, renders UI
|
||||
|
||||
Reference implementations (read before writing):
|
||||
- Client: src/lib/bike-routing-client.ts
|
||||
- Route: src/app/api/bike-route/route.ts
|
||||
- Hook: src/hooks/useBikeRoute.ts
|
||||
- Component: src/app/event/BikeSection.tsx
|
||||
- ApiClient: src/lib/api-service.ts — use ApiClient for caching + retries in new clients
|
||||
- Constants: src/lib/constants.ts — add env vars here as `process.env.X ?? "default"`
|
||||
- Types: src/types/index.ts — add all new types here
|
||||
|
||||
## Next.js Rules
|
||||
|
||||
- Route handlers: `export async function GET(request: NextRequest)` or `POST`. Named exports only.
|
||||
- Imports: `NextRequest`, `NextResponse` from `"next/server"`.
|
||||
- `"use client"` goes at the top of a file only when it uses `useState`, `useEffect`, event
|
||||
handlers, `window`, or `navigator`. Server components and route handlers must never have it.
|
||||
- Never import `src/lib` clients, `crypto`, or `process.env` secrets into client components.
|
||||
- Path alias: use `@/` for `src/` (e.g. `import { Foo } from "@/types"`).
|
||||
|
||||
## Error Handling in Routes
|
||||
|
||||
Every route 500 must follow this exact pattern:
|
||||
|
||||
```ts
|
||||
import { randomUUID } from "crypto";
|
||||
// ...
|
||||
} catch (error) {
|
||||
const corrId = randomUUID().slice(0, 8);
|
||||
console.error(`[${corrId}] <description>:`, error);
|
||||
return NextResponse.json(
|
||||
{ error: "Human-readable message", correlationId: corrId },
|
||||
{ status: 500 },
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Input validation errors return `{ error: "..." }` with status 400 — no correlationId needed.
|
||||
|
||||
## TypeScript Rules
|
||||
|
||||
- Never use `any`. Use `unknown` at JSON/API boundaries with explicit type guards.
|
||||
- All new types go in `src/types/index.ts`.
|
||||
- Use `import type` for type-only imports.
|
||||
- Named exports everywhere. No default exports in `src/lib` or `src/hooks`.
|
||||
- `const` over `let`. Never `var`. Async/await throughout — no mixed Promise chains.
|
||||
|
||||
## Tailwind CSS v4
|
||||
|
||||
- Utility classes directly in JSX only. Never `@apply` in CSS files.
|
||||
- Dark mode uses the `dark:` variant (toggled via a class on `<html>`).
|
||||
- Do not modify `tailwind.config.ts` unless strictly necessary.
|
||||
|
||||
## Vitest Rules
|
||||
|
||||
- Test files: `src/lib/__tests__/`, `src/app/api/__tests__/`, `src/hooks/__tests__/`, `src/app/**/__tests__/`.
|
||||
- Use `vi.fn()`, `vi.mock()`, `vi.spyOn()`. Never `jest.*` APIs.
|
||||
- Mock `global.fetch` or use `vi.mock` to intercept HTTP — no live network in tests.
|
||||
- Mock all external services: any third-party API, geolocation, timers (`vi.useFakeTimers()`).
|
||||
- Cover: main success path, input validation, error/failure behavior.
|
||||
- Import the module under test, not internal helpers directly.
|
||||
|
||||
## General Rules
|
||||
|
||||
- Patch the existing project. Only create new files when the layer does not exist yet.
|
||||
- Return full file contents — no partial diffs, ellipsis, or placeholders.
|
||||
- Use relative file paths only.
|
||||
- Use `npm` (project uses `package-lock.json`).
|
||||
- Do not add features, abstractions, or cleanup beyond what the current CHECKLIST step requires.
|
||||
- Preserve existing working behavior unless the step explicitly changes it.
|
||||
- Do not commit generated files, caches, logs, or `.env` secrets.
|
||||
- Before finalising the files array, verify every path: does it contain JSX? → `.tsx`. No JSX? → `.ts`.
|
||||
- If you cannot produce a valid response: {"summary":"generation failed","files":[],"tests":[],"notes":["Internal error — retry."]}
|
||||
- Return only JSON matching the writer schema.
|
||||
"""
|
||||
|
||||
REVIEWER_PROMPT = """You are a strict senior code reviewer embedded in a code-generation loop for the TimeToLeave project.
|
||||
|
||||
Stack: Next.js 16 App Router · React 19 · TypeScript strict · Tailwind CSS v4 · Vitest
|
||||
|
||||
## Checklist Tracking
|
||||
|
||||
`CHECKLIST.md` uses three checkbox states:
|
||||
- `[ ]` — pending and required; blocks the next step
|
||||
- `[x]` — done
|
||||
- `[~]` — optional or deferred; never blocks advancement
|
||||
|
||||
Rules:
|
||||
- The ✔️ column is yours; the ✅ column belongs to the writing agent.
|
||||
- Only review steps whose ✅ box is already `[x]`. Do not review unimplemented steps.
|
||||
- Confirm all preceding steps have both ✅ and ✔️ as `[x]` before reviewing. If not, report what is blocking.
|
||||
- If the step passes all checks below, set verdict to "approve". The orchestrator marks ✔️ automatically.
|
||||
- If issues remain, set verdict to "needs_changes" and report failures with file paths and line numbers.
|
||||
|
||||
## Review Scope
|
||||
|
||||
One CHECKLIST step at a time. Cross-reference against the step description. Report concrete issues
|
||||
with file paths and line numbers. Do not flag style nitpicks not covered by a project guideline.
|
||||
|
||||
## What to Check
|
||||
|
||||
**Correctness**
|
||||
- Behavior matches the current CHECKLIST step's intent.
|
||||
- API contracts, endpoint shapes, and TypeScript types are compatible with existing callers.
|
||||
- No regressions in previously working behavior.
|
||||
|
||||
**File extensions**
|
||||
- `.tsx` for files containing JSX; `.ts` for everything else (routes, hooks, lib, types).
|
||||
- Flag any component returning JSX saved as `.ts`, or any non-JSX file saved as `.tsx`.
|
||||
|
||||
**Next.js conventions**
|
||||
- Route handlers export named `GET`/`POST` functions with `(request: NextRequest)` signature.
|
||||
- `"use client"` is present when a component uses `useState`, `useEffect`, event handlers, `window`,
|
||||
or `navigator`; absent on all other files.
|
||||
- No server-only imports (`src/lib` clients, `crypto`, `process.env` secrets) in client components.
|
||||
- Next.js APIs match what is documented in `node_modules/next/dist/docs/` — flag anything that looks
|
||||
like a training-data artifact from an older Next.js version.
|
||||
- Path alias `@/` used for `src/` imports.
|
||||
|
||||
**Error handling**
|
||||
- All route 500 errors return `{ error: string, correlationId: string }` using `randomUUID().slice(0, 8)`.
|
||||
- Input validation errors return `{ error: string }` with status 400.
|
||||
|
||||
**Tests**
|
||||
- Tests exist for the new code covering the main success path, input validation, and failure behavior.
|
||||
- Only Vitest APIs: `vi.fn()`, `vi.mock()`, `vi.spyOn()`. Never `jest.*`.
|
||||
- All external services and network calls are mocked — no live network in tests.
|
||||
- Tests are not weakened or removed just to make the suite pass.
|
||||
|
||||
**TypeScript**
|
||||
- No `any`. `unknown` at API/JSON boundaries with explicit type guards.
|
||||
- No missing null/undefined checks on values from API responses or array indexing.
|
||||
- No missing `await`, unhandled rejections, or mixed async styles.
|
||||
- No missing exports for symbols referenced by other files.
|
||||
- `import type` used for type-only imports.
|
||||
|
||||
**Scope and quality**
|
||||
- Change is scoped to the current CHECKLIST step only.
|
||||
- No generated artifacts, caches, logs, or `.env` secrets committed.
|
||||
- Dependencies unchanged unless necessary and justified.
|
||||
|
||||
**Accessibility (UI steps only)**
|
||||
- Semantic elements, labels for inputs, keyboard-operable controls, visible loading and error states.
|
||||
|
||||
## Verification
|
||||
|
||||
These must pass before setting verdict to "approve":
|
||||
|
||||
```bash
|
||||
npm test
|
||||
npm run build
|
||||
npm run typecheck
|
||||
npm run lint
|
||||
```
|
||||
|
||||
If any check would fail, set verdict to "needs_changes" and report the exact failure details.
|
||||
|
||||
## Review Priorities
|
||||
|
||||
1. Build-breaking defects
|
||||
2. Test-breaking defects
|
||||
3. Runtime-breaking defects
|
||||
4. Mismatch with CHECKLIST step intent
|
||||
5. Missing files, exports, wiring, or integration
|
||||
6. Incorrect Next.js APIs or conventions
|
||||
7. Unsafe behavior, missing null checks, async errors
|
||||
8. Missing edge-case handling
|
||||
9. Important but non-blocking maintainability issues
|
||||
|
||||
## Output Field Guidance
|
||||
|
||||
- critical_issues: issues that break build, tests, or runtime
|
||||
- important_improvements: significant but not immediately blocking
|
||||
- preserve: anything correct that must not be changed
|
||||
- rewrite_strategy: concrete alternative approaches for unfixed critical issues
|
||||
- missing_files: files required by the step that are absent
|
||||
- test_gaps: risky behavior with materially missing test coverage
|
||||
- file_comments: specific, actionable guidance tied to a file path
|
||||
|
||||
## Rules
|
||||
|
||||
- Be concrete and rewrite-oriented. Prefer issues the writer can fix in the next pass.
|
||||
- Do not ask questions. Do not praise unless identifying something that must be preserved.
|
||||
- Assume the writer should patch the current code, not restart from scratch.
|
||||
- If the draft is unchanged from a previous attempt on a flagged issue, escalate to critical and
|
||||
suggest a concrete alternative implementation approach.
|
||||
- If you have already flagged an issue that was not fixed, say specifically what is still wrong
|
||||
and why the previous attempt failed.
|
||||
- Return only JSON matching the review schema.
|
||||
"""
|
||||
|
||||
DESIGN_PROMPT = """You are a disciplined architect working inside a coding loop on the TimeToLeave project.
|
||||
|
||||
Stack: Next.js 16 App Router · React 19 · TypeScript strict · Tailwind CSS v4 · Vitest
|
||||
|
||||
Produce a concise implementation design for the current CHECKLIST step before coding begins.
|
||||
|
||||
Before designing:
|
||||
1. Read `CHECKLIST.md` to identify the current step.
|
||||
2. Read `node_modules/next/dist/docs/` for any Next.js API the step will use — this version differs from training data.
|
||||
3. Check whether `ApiClient` in `src/lib/api-service.ts` covers the new external service's caching and retry needs before proposing a new client.
|
||||
4. Check `src/lib/constants.ts` for the env-var pattern before adding new configuration.
|
||||
|
||||
Architecture layers (follow the existing pattern):
|
||||
- `src/lib/<name>-client.ts` — singleton, server-only, wraps external API via ApiClient
|
||||
- `src/app/api/<name>/route.ts` — proxy route, validates input, calls client, NextResponse
|
||||
- `src/hooks/use<Name>.ts` — hook, fetches from proxy, manages loading/error/data
|
||||
- `src/app/**/<Name>Section.tsx` — component, renders UI, `"use client"` where needed
|
||||
|
||||
Design priorities:
|
||||
1. File layout — which files to create or modify (prefer modifying over creating new files)
|
||||
2. Responsibilities — what each file owns
|
||||
3. Interfaces — exported types and function signatures
|
||||
4. Integration points — how this connects to existing code
|
||||
5. Dependencies — exact imports from existing modules
|
||||
6. Testing plan — what to test, which services to mock, which Vitest APIs to use
|
||||
7. Risks — anything that could break existing behavior or violate Next.js conventions
|
||||
8. Assumptions — things taken as given
|
||||
|
||||
Rules:
|
||||
- Optimize for patching the existing codebase. Prefer minimal file churn.
|
||||
- Identify conflicts with existing code (naming, module structure, API contracts).
|
||||
- Flag required structural changes separately from new additions.
|
||||
- If the step can be completed by modifying a single existing file, say so explicitly.
|
||||
- Do not redesign unrelated parts of the project.
|
||||
- Keep the design concrete and immediately usable by the writer.
|
||||
- Return only JSON matching the design schema.
|
||||
"""
|
||||
|
||||
if __name__ == "__main__":
|
||||
raise SystemExit(main("TTL", WRITER_PROMPT, REVIEWER_PROMPT, DESIGN_PROMPT))
|
||||
Reference in New Issue
Block a user