geo/task_plan.md

Task Plan: GEO admin-web backend completion and frontend foundation

Goal

Finish the completed backend verification/implementation chain, then resume the interrupted work by establishing the missing frontend foundation for admin-web so it can authenticate against tenant-api and render the first dashboard slice.

Current Phase

Phase 10

Phases

Phase 1: Progress Verification

• Understand user intent
• Identify constraints and requirements
• Compare repository state with the 9-step plan
• Document findings in findings.md
• Status: complete

Phase 2: Gap Analysis and Scope Lock

• Confirm the earliest incomplete step
• Read the relevant sections of the design doc
• Define the exact implementation slice for this turn
• Status: complete

Phase 3: Implementation

• Implement the missing backend code/config/schema/tests
• Keep changes aligned with the design doc and existing structure
• Update findings/progress after meaningful milestones
• Status: complete

Phase 4: Testing & Verification

• Run targeted commands and tests
• Confirm the step acceptance criteria or record gaps
• Fix issues found during verification
• Status: complete

Phase 5: Delivery

• Summarize step completion status with evidence
• Highlight remaining gaps and risks
• Deliver next-step outcome to the user
• Status: complete

Phase 6: Frontend Scope Recovery

• Recover the interrupted task context from planning files and Claude artifacts
• Confirm whether frontend work already exists in the repository
• Lock the smallest useful frontend slice for this turn
• Status: complete

Phase 7: Frontend Foundation

• Scaffold the pnpm workspace and shared frontend packages
• Create the apps/admin-web Vite + Vue 3 application skeleton
• Wire environment/config conventions for local API access
• Status: complete

Phase 8: Admin-Web Initial Features

• Implement auth state, login flow, and route guarding
• Implement the main application shell and navigation
• Implement the workspace dashboard with live backend data
• Status: complete

Phase 9: Frontend Verification & Delivery

• Run install/build checks for the new frontend workspace
• Record remaining frontend gaps and follow-up slices
• Deliver the resumed-task status to the user
• Status: complete

Phase 10: Interface Coverage Audit & Visual Mapping

• Inventory all currently exposed tenant-facing backend interfaces
• Map interface groups to real admin-web pages
• Recover the reference layout structure from docs/refer screenshots, including positional relationships
• Status: complete

Phase 11: Admin-Web Full Interface Delivery

• Implement templates/articles frontend coverage against current backend APIs
• Implement brands/keywords/questions/competitors frontend coverage against current backend APIs
• Realign the shell and page layouts to the reference screenshot structure
• Restore pnpm dev:admin and pnpm typecheck:admin after the frontend refactor introduced compile/runtime regressions
• Establish the i18n and style hygiene baseline for the pages touched in this turn
• Status: in_progress

Phase 12: Verification & Delivery

• Run frontend type/build verification
• Spot-check the main interaction flows against the live backend
• Update planning files and deliver the completed scope
• Status: pending

Key Questions

1. Which of the 9 steps are already implemented versus partially complete?
2. What is the earliest step whose acceptance criteria are not yet met?
3. What concrete code changes are required now to advance that step safely?

Decisions Made

Decision	Rationale
Use file-based planning for this task	Verification plus implementation will span multiple reads, edits, and test runs
Treat the earliest incomplete step as the current development target	Keeps the roadmap sequential and avoids skipping acceptance gaps
Lock the current implementation target to Step 4	sqlc generation is broken and repository wrappers are absent, making it the earliest failed acceptance gate
Continue into the Step 5 refresh-rotation fix after Step 4 passed locally	The next acceptance gap was small, isolated, and directly adjacent to the auth module already being modified
Resume from the completed backend chain by building the missing admin-web foundation	The repository has no frontend apps, so UI integration cannot start without workspace scaffolding
Keep this turn scoped to admin-web rather than also creating ops-admin-web	The available backend is tenant-api; platform-side APIs and pages are not yet present in the repo
Use a pnpm workspace with shared packages from day one	Matches the architecture doc and avoids painting the repo into a single-app corner
Stop using Gemini for this turn after the user changed direction	Avoids spending more time on an unavailable external model path and keeps momentum inside the repo
Verify the first frontend slice with a real browser pass once Playwright became available again	Browser-level validation catches interaction bugs that install/build checks miss
Use the current backend route graph as the implementation boundary for this turn	The user asked for frontend coverage of existing interfaces, so pages without APIs stay non-primary
Reconstruct the screenshot layouts from visual position data, not OCR text alone	The user explicitly asked to follow image design including element placement
Move the quota card into the left sidebar footer and use page-level hero sections	This matches the reference screenshots more closely than the previous generic topbar layout

Errors Encountered

Error	Attempt	Resolution
None yet	1	N/A
make sqlc-generate failed because sqlc.yaml points to ../../migrations/, which resolves to server/internal/migrations	1	Fix schema path to repository-relative ../../../migrations/ and then generate code
make lint initially failed on several errcheck and one ineffassign warning	1	Fixed transaction defers, the middleware test Redis set call, and the dead increment in article_service.go
Gemini CLI gemini-3.1-pro-preview returned 429 MODEL_CAPACITY_EXHAUSTED repeatedly	1	Stopped the Gemini path after the user requested not to use Gemini anymore
Playwright MCP navigation failed locally because it attempted to create /.playwright-mcp	1	Fell back to preview HTTP checks instead of blocking the turn on Playwright environment setup
Login button click did not trigger the sign-in flow in browser testing even though the backend endpoint worked	1	Bound the primary login button directly to handleSubmit and re-ran browser verification until the route change succeeded

Notes

• Re-check task_plan.md before major implementation decisions.
• Record concrete evidence for each claimed completed step.
• Frontend scope for this turn is limited to the tenant-facing admin-web shell, not the platform ops console.
• Visual references for this turn must be treated as layout guides, not just copy decks.