- Custom SQLite task manager replacing TickTick wrapper - 73 tasks migrated from TickTick across 15 projects - RRULE recurrence engine with lazy materialization - Dashboard tasks widget (desktop sidebar + mobile card) - Tasks page with project tabs, add/edit/complete/delete - Security: locked ports to localhost, removed old containers - Gitea Actions runner configured and all 3 CI jobs passing - Fixed mobile overflow on dashboard cards - iOS Capacitor app shell (Second Brain) - Frontend/backend guide docs for adding new services - TickTick Google Calendar sync re-authorized Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
78 lines
3.4 KiB
Plaintext
78 lines
3.4 KiB
Plaintext
Work in the `platform` repo and correct your previous remediation pass.
|
|
|
|
Your previous status report overstated completion. I do not want optimistic summaries or "close enough" fixes.
|
|
|
|
You must re-audit the current repo state first and compare every completion claim against the actual code.
|
|
|
|
Critical instruction:
|
|
- Do not mark an issue `Completed` unless the code path is actually fixed end-to-end.
|
|
- If any part of an issue is still present in code, the issue is not complete.
|
|
- Renaming, documenting, or partially reducing a problem does NOT count as fully fixed unless the underlying behavior is actually resolved.
|
|
- If something is only improved but not eliminated, keep it `Partial`.
|
|
|
|
I want correctness, not a clean-looking report.
|
|
|
|
Specific examples of what was overstated and must be handled properly:
|
|
|
|
1. Trips TLS verification
|
|
- Do not say Trips TLS is fixed unless all remaining `ssl.CERT_NONE` and `check_hostname = False` usage is removed or intentionally narrowed with a strong documented reason.
|
|
- Re-check every remaining occurrence in `services/trips/server.py`.
|
|
- Verify the real runtime call paths, not just one helper or one integration.
|
|
- If any unsafe TLS bypass remains in active code, the issue is still partial.
|
|
|
|
2. Inventory and Budget CORS
|
|
- Do not say CORS is removed unless `app.use(cors())` is actually gone or replaced with a constrained, justified configuration.
|
|
- Re-check:
|
|
- `services/inventory/server.js`
|
|
- `services/budget/server.js`
|
|
- If permissive CORS still exists in either service, do not call that fixed.
|
|
|
|
3. Settings disconnect safety
|
|
- Do not say disconnect safety is fixed unless the Settings page actually has a confirmation or another real guardrail before disconnecting a service.
|
|
- Re-check:
|
|
- `frontend-v2/src/routes/(app)/settings/+page.svelte`
|
|
- If clicking Disconnect still immediately disconnects, this is not fixed.
|
|
|
|
4. Stale test/debug cleanup
|
|
- Do not say `/test` cleanup is complete while stale references remain in comments, logs, or startup output.
|
|
- Re-check:
|
|
- `services/inventory/server.js`
|
|
- If comments or logs still refer to `/test`, cleanup is incomplete.
|
|
|
|
5. Cosmetic vs real authz
|
|
- Do not treat navbar hiding as authorization.
|
|
- If app visibility is only cosmetic and direct URLs still work, say that explicitly.
|
|
- Do not write language implying hidden apps are access-controlled unless route-level enforcement exists.
|
|
|
|
Required workflow:
|
|
1. Re-audit the current repo state first.
|
|
2. List every claim from the previous "final status" that is not actually true in code.
|
|
3. Fix the remaining code completely where feasible.
|
|
4. Re-verify after each fix.
|
|
5. Only then update issue comments and status.
|
|
|
|
When deciding whether an issue is complete:
|
|
- `Completed` means the underlying behavior is actually resolved in code and verified.
|
|
- `Partial` means some meaningful work is done, but any real part of the problem still exists.
|
|
- `Blocked` means you cannot finish because of an external dependency or operational prerequisite.
|
|
|
|
Do not use these as excuses:
|
|
- "It is harmless"
|
|
- "It is dead code"
|
|
- "It is okay because internal"
|
|
- "The naming is clearer now"
|
|
- "The doc explains it"
|
|
|
|
Those may be useful notes, but they do not make an issue complete by themselves.
|
|
|
|
Expected output:
|
|
- Start with a short audit of inaccurate prior claims.
|
|
- Then fix the code.
|
|
- Then provide:
|
|
- `Completed:`
|
|
- `Partial:`
|
|
- `Blocked:`
|
|
- `Manual ops actions:`
|
|
|
|
Do not rotate or change admin credentials during this pass.
|