root/geo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(plan): mark generated-code drift phases 69-70 complete

Browse Source 
- Record deterministic sqlc output (identical checksum across runs) and
  the migration source of the media-supply favorite tables
- Note external commits 3037cfe/6adcec4 that landed the generated fix
  and that CI reproduction now passes on origin/main
- Advance task plan to Phase 70 complete with tests and scope guard green
This commit is contained in:
liangxu
2026-07-18 21:16:08 +08:00
parent efe1cde77c
commit 89a300c458
3 changed files with 15 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
findings.md
+5
View File
@@ -20,6 +20,11 @@
- Version-mismatch hypothesis is falsified. The next deterministic probe is the exact CI generation command.
- Exact CI generation reproduces a one-file diff: `generated/models.go` gains 26 lines for `MediaSupplyFavoriteGroup`, `MediaSupplyFavoriteOwner`, and `MediaSupplyFavoriteResource` immediately before `MediaSupplyOrder`.
- Root cause: the schema already contains the three media-supply favorite tables, but their generated sqlc model structs were not committed. The reported `MediaSupplyOrder` line is only the diff insertion boundary.
- A second `make sqlc-generate` produced the identical SHA-256 checksum, proving sqlc output is deterministic and stable.
- Source tables come from migration `20260710183000_create_media_supply_favorites.up.sql`.
- CI-adjacent verification passes: tenant SQL scope guard and `make test` (`go test ./... -count=1`).
- External Git activity during this turn committed and pushed the generated fix: commit `3037cfe` adds the three missing models, and `origin/main` now points at follow-up commit `6adcec4`.
- Final CI reproduction passes on `6adcec4`: running sqlc v1.30.0 generation leaves the committed generated directory unchanged.
- The reported `MediaSupplyOrder` is generated in `server/internal/tenant/repository/generated/models.go` around line 699.
- Screenshot evidence: on client `e83077a0...`, `monitoring_collect:7995` for Doubao failed with `doubao_challenge_required`, while later Doubao task `monitoring_collect:7989` also appeared as failed with the same message.
- Screenshot refinement: the first challenged desktop task `#7224` shows attempt 1, while later `monitoring_collect:7989` shows attempt 0 and the same copied challenge message. This indicates the later task was bulk-terminalized without adapter execution, but recorded as `failed`, making cancellation look like another failed attempt.