refactor: restructure repo — Go code to root, module path → github.co…#3
Conversation
…m/Koopa0/koopa0.dev - Move all Go source from backend/ to repo root - Module path: github.com/koopa0/blog-backend → github.com/Koopa0/koopa0.dev - Update 125 Go files with new import path - Merge backend/CLAUDE.md into root CLAUDE.md (single source of truth) - Merge backend/docs/ and backend/scripts/ into root - Move backend/.claude/ to root .claude/ - Update docker-compose.yml build contexts (./backend → .) - Update deploy.yml VPS path (~/blog → ~/koopa0.dev) - Add .dockerignore to exclude frontend from Go Docker builds - All 35 test packages pass, go build/vet clean
🤖 Augment PR SummarySummary: This PR refactors the repo into a true monorepo layout by moving the Go backend from Changes:
Technical Notes: Primary impact is path/module renaming; runtime behavior should remain the same, but local/dev and deployment configs need to stay in sync with the new root build context. 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
|
|
||
| # === GitHub === | ||
| GITHUB_WEBHOOK_SECRET=your-webhook-secret-here | ||
| GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx |
There was a problem hiding this comment.
.env.example:18 — The placeholder GITHUB_TOKEN=ghp_... looks like a real GitHub PAT format and can trigger secret-scanning / security tooling even when it’s intended as an example. That can create noisy alerts or CI policy failures for contributors.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| SITE_URL=http://localhost:8080 | ||
|
|
||
| # === Database === | ||
| DATABASE_URL=postgres://blog:blogpass@localhost:5432/blog?sslmode=disable |
There was a problem hiding this comment.
.env.example:7 — DATABASE_URL here points at localhost with blog:blogpass, but the default docker-compose.yml uses a different host/user (postgres, koopa). This mismatch can make “copy .env.example and run compose” setups fail or be confusing.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| @@ -1,4 +1,4 @@ | |||
| module github.com/koopa0/blog-backend | |||
| module github.com/Koopa0/koopa0.dev | |||
There was a problem hiding this comment.
go.mod:1 — The module path is now github.com/Koopa0/koopa0.dev, which won’t be fetchable via go get unless the GitHub repo is renamed (or you’re using a vanity import setup). If the repo remains Koopa0/blog, downstream consumers/build systems may break when resolving the module.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
|
|
||
| > 45 tools across 4 domains. Last audit: 2026-03-26. | ||
| > Server: single Go binary (`/Users/koopa/blog/backend/`) + PostgreSQL. | ||
| > Server: single Go binary (`/Users/koopa/blog/./`) + PostgreSQL. |
There was a problem hiding this comment.
docs/MCP-TOOLS-REFERENCE.md:4 — The server location string now reads /Users/koopa/blog/./, which is syntactically valid but easy to misread as a typo. This can confuse readers about the intended on-disk layout after the restructure.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| backend: | ||
| build: | ||
| context: ./backend | ||
| context: . |
There was a problem hiding this comment.
docker-compose.yml:64 — After updating build context to the repo root, the compose file still references env vars like NOTION_PROJECTS_DB/NOTION_TASKS_DB that are no longer present in .env.example. That drift makes it unclear which variables are actually required for a working local/prod compose deploy.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
HIGH fixes: - #1-2: GoalDetail projects are goal siblings, not milestone children (projects.goal_id → goals.id, no milestone_id FK exists) Restructured GoalDetail: milestones[] + projects[] as separate arrays MEDIUM fixes: - #3: signal_type uses weakness/improvement/mastery (not misconception) - #4: outcome uses schema 7-values (incomplete, not partial) - #5: duration_minutes not duration_seconds - #6: removed ease_rating (FSRS rating is in review_logs, not attempts) - #8: mastery is aggregated from observations, not a stored score - #12: drop only affects daily_plan_item status, doesn't delete task - #13: ClarifyAsInsight requires invalidation_condition (schema NOT NULL) LOW fixes: - #7: session start uses session_mode, focus_concepts noted as metadata - #9: concept drilldown uses observation_trend, not mastery_trend - #10: removed stale directive schema note (resolved_at already exists) NEW: - #11: Added Learning Plans API section (§7.5) — plans list, detail, item status update with mandatory reason for completions - Added PlanStatus, PlanItemStatus, LearningPlanSummary, LearningPlanDetail, PlanItemDetail, PlanProgress types to admin.model.ts
Dashboard (new page at /admin/dashboard): - Trends analytics answering '系統方向對嗎？' (not stat cards) - 4-card grid: execution velocity, goal health, learning signals, content+inbox - Every metric shows trend direction + comparison with last period - Compact directive health footer - DashboardTrends model + DashboardService with mock data - Route + sidebar nav added (between Today and Inbox) Schema alignment fixes (round 2): - #1: GoalBreadcrumb simplified — removed milestone_id/title (no FK exists) - #2: streak marked as derived (computed from sessions, not stored) - #3: Added missing learning plan management endpoints (add/remove/reorder/update) - #4: DirectiveLifecycle simplified to 3 values + has_report boolean - #5: Domain examples changed from 'algorithms' to 'leetcode' - #6: Added GET /api/admin/learn/review-queue (FSRS detail endpoint) - #7: estimated_minutes marked as derived from tasks table
1 participant
…m/Koopa0/koopa0.dev