You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A tester run (sandbox, end-to-end, real LLM coach) surfaced a cluster of defects — #115, #116, #117, #118, #119, #120. The core engine is solid: ingestion, analytics (TSS/PMC), and grounded coaching all compute correctly and honestly — the tester found zero numeric/correctness bugs there. The rot is concentrated in ONE layer: the last mile to the user — state reporting, the async/sync contract, user-facing copy, and onboarding.
Why this is an epic, not six tickets
Several of these are direct spec/ violations (API-R46, QUAL-R13), and that is the tell: the spec was treated as a SHAPE to satisfy, not a BEHAVIOR to deliver. Concretely:
ImportJob.status: "queued|processing|done|failed" exists as a type, but done/failed are unreachable in the code (Import job status is stuck at "queued" forever — done/failed never reached #115) — the status machine was never wired, even though API-R46 depends on done → recent_ready → complete. The type "implements the spec"; the behavior does not.
The uncomfortable part: all of this passed review and a green test suite. So the review nodded "looks ok" without checking the actual spec'd behavior, and/or the tests asserted something OTHER than the contract — the same vacuous-test disease #93 already had to clean up in another layer. We can NOT keep pretending a surface is spec-compliant because the types match, the PR was approved, and tests are green, when the behavior the spec and the user rely on simply is not there. Так не пойдёт.
Definition of done (the bar this epic sets — for each member AND as policy for this layer)
The fix delivers the spec'd BEHAVIOR end-to-end, not just the type / happy path. (e.g. upload → ImportJob.status actually reaches done → GET /v1/onboarding/status actually reaches complete.)
Independent review confirms spec ⇄ code correspondence BOTH ways — the reviewer verifies the actual behavior against the requirement IDs, not "вроде ок".
spec/ extended/clarified in the SAME PR wherever the contract was ambiguous enough to let shape-without-behavior through.
This is the same root cause the project already paid for once (#93). Let us not re-pay it by shipping shape without behavior.
What this is
A tester run (sandbox, end-to-end, real LLM coach) surfaced a cluster of defects — #115, #116, #117, #118, #119, #120. The core engine is solid: ingestion, analytics (TSS/PMC), and grounded coaching all compute correctly and honestly — the tester found zero numeric/correctness bugs there. The rot is concentrated in ONE layer: the last mile to the user — state reporting, the async/sync contract, user-facing copy, and onboarding.
Why this is an epic, not six tickets
Several of these are direct
spec/violations (API-R46, QUAL-R13), and that is the tell: the spec was treated as a SHAPE to satisfy, not a BEHAVIOR to deliver. Concretely:ImportJob.status: "queued|processing|done|failed"exists as a type, butdone/failedare unreachable in the code (Import job status is stuck at "queued" forever —done/failednever reached #115) — the status machine was never wired, even though API-R46 depends ondone → recent_ready → complete. The type "implements the spec"; the behavior does not.202 queuedjob contract — the contract lies about the shape of the work (root of Import job status is stuck at "queued" forever —done/failednever reached #115)./v1/sync/runsays "we're pulling in your training" with zero connections (POST /v1/sync/runreturns a falsely-reassuring 202 when there are no connections; no way to see it did nothing #118) and the intervals 422 blames a valid key (intervals.icu connect 422 message blames the user's key instead of saying the connector is inert in OSS #119).The uncomfortable part: all of this passed review and a green test suite. So the review nodded "looks ok" without checking the actual spec'd behavior, and/or the tests asserted something OTHER than the contract — the same vacuous-test disease #93 already had to clean up in another layer. We can NOT keep pretending a surface is spec-compliant because the types match, the PR was approved, and tests are green, when the behavior the spec and the user rely on simply is not there. Так не пойдёт.
Members
spec/violations:done/failednever reached #115 — import status never reachesdone/failed(API-R46 / API-R33)POST /v1/sync/runreturns a falsely-reassuring 202 when there are no connections; no way to see it did nothing #118 —sync/runmisleading status copy with no connections (QUAL-R13)Same-layer roughness:
current_sportdependency)--4.8formattingDefinition of done (the bar this epic sets — for each member AND as policy for this layer)
ImportJob.statusactually reachesdone→GET /v1/onboarding/statusactually reachescomplete.)done/the honest copy, is NOT coverage).spec/extended/clarified in the SAME PR wherever the contract was ambiguous enough to let shape-without-behavior through.This is the same root cause the project already paid for once (#93). Let us not re-pay it by shipping shape without behavior.