melosh/mal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: remove completed plans 009 and 010

Browse Source
This commit is contained in:
mkelvers
2026-06-27 17:46:56 +02:00
parent 177081edd0
commit 1d9840f2b9
2 changed files with 0 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
plans/009-add-ci-for-existing-verification-command.md
View File

@@ -1,43 +0,0 @@
---
finding: "Add CI for the existing verification command"
catalog: "DX / Tooling"
impact:
"Local checks are well-defined, but nothing checked in runs them consistently before changes land."
base_commit: "0d31d46"
---
## Effort
S - add one workflow mirroring documented local commands.
## Risk
LOW - CI should run existing verification rather than introduce new policy.
## Confidence
HIGH - no GitHub Actions workflow was present, while local verification is documented.
## Evidence
- `justfile:40` defines `check` as the full local verification command.
- `package.json:11-18` exposes lint, test, and typecheck scripts.
- `README.md:130-138` documents `just check` as linting, tests, typechecking, and full build.
- No `.github/workflows/*` files were found during recon.
## Resolution Approach
Add a GitHub Actions workflow that installs the pinned toolchain from `.mise.toml`, installs Bun
dependencies with the lockfile, and runs `just check`. The workflow should mirror documented local
behavior as closely as possible.
This plan depends on fixing the current Go lint baseline first. Do not add CI while `just check` is
known to fail locally, unless the workflow is intentionally introduced as failing and the maintainer
explicitly wants that.
Use caching only if the first version is too slow. Start simple: checkout, setup mise or equivalent,
`mise install`, `bun install --frozen-lockfile`, `just check`. Ensure CGO/SQLite prerequisites are
available on the runner.
Verify locally with `just check` after plan 001 is complete. Verify workflow syntax using GitHub’s
normal workflow validation when pushed.

46
plans/010-add-watchlist-import-restore.md
View File

@@ -1,46 +0,0 @@
---
finding: "Add watchlist import / restore"
catalog: "Direction"
impact:
"Local-first users can export watchlist state but cannot round-trip it into a new install or after
data loss."
base_commit: "0d31d46"
---
## Effort
M - server-side CSV parsing, validation, UI, and service tests.
## Risk
MED - import needs careful duplicate handling, status validation, and partial-failure reporting.
## Confidence
HIGH - export exists and the inverse capability is missing.
## Evidence
- `templates/watchlist.gohtml:18` exposes an “Export to CSV” action.
- `static/watchlist.ts:317-343` implements CSV export from rendered watchlist rows.
- `internal/watchlist/handler.go:21-25` registers update, delete, continue-watching delete, and page
routes, but no import route.
## Resolution Approach
Treat this as a product/design implementation plan, not a bug fix. Define the import contract to
match the existing export columns: `mal_id`, `title`, `status`, and `updated_at`. The server should
validate `mal_id` and supported status values, ignore or display title only as user context, and
decide whether `updated_at` is informational or preserved.
Prefer a dry-run or preview step before mutation. The preview should report valid rows, duplicates,
unknown statuses, malformed IDs, and rows that would update existing entries. The final apply step
should upsert valid watchlist entries for the current authenticated user and return row-level
results.
Add service and handler tests for valid import, duplicate rows, invalid statuses, malformed CSV,
empty files, and partial success. Keep import scoped to watchlist entries; do not attempt to restore
playback progress or continue-watching state unless a separate plan expands the export schema.
Verify with `go test ./internal/watchlist ./...`, `bunx tsc -p tsconfig.json --noEmit`, and
`bun run lint:ts` if frontend UI is added.