stride

Imported from eschizoid/stride (skills/stride/SKILL.md). Install upstream with npx skills add eschizoid/stride --skill stride. Copyright stays with the author.

Stride — local training engine

stride syncs the user's Strava data into ~/.stride/db.sqlite and computes training metrics deterministically. You are the coach brain; stride is the data engine. Don't recompute what stride already computed. Consume its JSON. Never do training math yourself: read stride's numbers, add judgment.

Coaching workflow

1. stride sync --json is the ONE command that pulls data from Strava (#232). It re-lists a rolling 30-day window so recent edits self-heal, then drains every activity still missing streams, paced against Strava's limits. A first run on a fresh install is the whole history pull. It ends in the usual envelope (schemas/v3/sync.json) with progress on stderr. Read resumable to decide whether to run it again. It is usually pending_streams > 0. It is also true when the LISTING was cut short and the queue is empty, and when the run was refused BEFORE its first request because the day was already spent. Read stopped for why the run ended (complete / budget_reached / rate_limited / daily_cap_reached / list_rate_limited / list_daily_cap_reached). The two list_* tokens mean a 429 on the ACTIVITY LIST rather than a stream. That refusal leaves the listing INCOMPLETE and prunes nothing. Rows are missing, so synced and pruned describe a partial run. list_daily_cap_reached is that refusal on a day whose allowance is already gone: both facts at once. THE REMEDY DIFFERS, and the remedy is the point of the distinction. budget_reached, rate_limited and list_rate_limited all clear when Strava's 15-minute window rolls over, so tell the athlete about fifteen minutes. daily_cap_reached clears at UTC MIDNIGHT, and so does list_daily_cap_reached. Tell them tomorrow. Advising fifteen minutes there is an instruction that cannot succeed. This file used to say exactly that ("all non-complete reasons stop on the 15-MINUTE window ... NOT tomorrow") for every stop, including that one. A first sync on a large history takes one run per 15-minute window, bounded by Strava's daily read allowance rather than by a fixed number of runs. Stride counts its own reads against that allowance, so a few thousand activities spans a day or two. The run that exhausts the day says so. Each run says how far it got. Every stored stream is permanent, so re-running is never wasted. The count lives in two config rows, strava_reads_today and strava_reads_day. The second is a UTC day number. A stamp that is not today IS the reset, so nothing runs at midnight. The engine maintains both rows. The only reason to touch them is the escape hatch stride names if the count is unreadable: stride config set strava_reads_today 0. complete can still leave work: a stream body that does not decode is skipped WITHOUT storing, so it retries next run and shows up in streams_skipped. An activity Strava has no streams for is NOT that case. A 404 stores an empty marker and retires it permanently (#218). Do not loop on resumable alone. The rule is streams_fetched == 0 with resumable: true. Stop and report. That one condition covers both ways a run can do nothing and still ask for another: unreadable bodies (streams_skipped > 0, which will keep returning the identical envelope), and a rate limit (stopped: "rate_limited", where the wait is ~15 minutes and the command returns immediately rather than blocking). The earlier rule keyed on streams_skipped > 0 alone and did NOT fire on the rate-limited shape, where a loop can issue dozens of Strava requests per second. stride sync --all forces a full re-list from scratch. It is a dev-mode escape hatch and the only way a deletion in OLD history propagates. Normal use never needs it. No API credentials (Strava requires a subscription for API access since June 2026): stride import <export.zip|dir> --json loads a Strava account export. The import is summary-level activities only (no streams), idempotent, and limited to English exports.
2. stride analyze --json computes metrics for new/invalidated activities. It is idempotent and prints a count plus a form verdict. The full report lives in summary. If any stored streams won't decode it says "N had unreadable stream data", and they retry next sync.
3. stride plan --json is THE payload for weekly planning: summary + the open sessions + last-14d activities + plan_history_28d + adherence_28d + data_freshness, in one call. plan_history_28d and adherence_28d close the loop: they record what was targeted and what actually happened. Without them each week's plan would be a fresh guess, so read them before proposing anything. data_freshness reports how current the rest of the payload is, as four measurements. You decide what counts as too stale to plan from. Use stride summary --json alone for quick check-ins.
4. Reason: polarization, zone gaps, form (TSB), FTP staleness, sport balance. AND reconcile the open plan against recent activities (match by date/type, then stride complete <session_id> <activity_id> --json for each match).
5. Plan the coming week: stride week add <YYYY-MM-DD> <type> "<detail>" "<rationale>" ["<target>"] --json
   • type is the INTENSITY INTENT, not the sport: vo2max | threshold | endurance | recovery | strength | rest (free-form ok). The sport/modality goes in detail ("easy row...", "outdoor ride..."): type answers why/how hard, detail answers what exactly.
   • the optional target is a strict literal <reps>x<mm:ss>@<watts>W (3x12:00@230W, ADR 0014) stored BESIDE the prose, power only. Add it when the session genuinely has numbers; prose stays canonical and a prose-only session is unchanged. The echo carries target_known with impossible-zero magnitudes (target_reps, target_dur_s, target_watts); plan's open sessions carry the same four. A revise REPLACES the whole prescription, so re-planning a date WITHOUT the target clears it. Malformed literals refuse with bad_target.
   • an EVENT the athlete is training toward: stride event add <YYYY-MM-DD> "<name>" --json (future dates only; removable via stride event remove <id>, since a target is not a record). stride events --json returns {projected_from, baseline_known, ftp_known, events:[{id, event_date, name, days_away, ctl, atl, tsb, planned_in_window, sessions_projected}]}. The payload is CTL/ATL/TSB projected onto each event date by the SAME recurrence daily_load runs, folded over the open plan's structured targets. Untargeted sessions contribute zero, and the two counts say how blind the projection is. baseline_known: false means no computed history, so every number is decay over zero. The window is (projected_from, event_date]. A session dated ON the baseline day (usually today) is excluded, because the measured baseline already contains today. Asking what tonight's session does to Saturday means planning it for a day the baseline has not absorbed yet. The projection is ADR 0010 arithmetic: stride projects the recorded plan's consequences and never proposes, ranks, or solves for a plan. Whether to CHANGE the plan in response is your judgment, and "on track" is a sentence only you may write.
   • TAPER planning: stride project <YYYY-MM-DD> ["<date>=<target>,..."] --json returns {target_date, days_away, projected_from, baseline_known, ftp_known, plan_source, ctl, atl, tsb, sessions_considered, sessions_projected, hypothetical}, the same walk at any horizon. Bare = the recorded open plan; with the literal, the walk runs over YOUR hypothetical plan INSTEAD (each pair <YYYY-MM-DD>=<RxMM:SS@WWWW>), echoed back in hypothetical (dates verbatim, targets as parsed canonical fields) and never stored. Compare candidate tapers by calling it once per candidate. Stride will not solve for the plan that reaches a TSB, even if you name one. That inverse is prescription (ADR 0010), and the judgment is yours.
   • completing a TARGETED session against an activity reports the arithmetic: complete returns {target_known, target_reps, target_dur_s, target_watts, detected_known, detected_reps, detected_mean_dur_s, detected_mean_watts, reps_delta, watts_pct}, the recorded target beside the detected shape. reps_delta/watts_pct mean something only when BOTH flags are true; a session without power segments compares to nothing and says so. Whether the numbers constitute hitting the workout is YOUR judgment. Stride states them.
   • re-planning a date REVISES its open session in place (the response echoes the same id). A plan edit is not a skip, so you can just week add again to change a day. Re-planning never leaves skipped tombstones. Reserve skip for a session that was going to happen and didn't (a real adherence miss).
   • complete/skip also REFUSE unknown ids (error code session_not_found / activity_not_found / bad_id), so a typo can't silently desync the log. Check for an error field instead of assuming success.
   • a session that didn't happen: stride skip <id> "<reason>" [activity_id|none] --json. The optional link names the activity done INSTEAD (a substitution, not a completion; rendered → id in week). none releases a link, and a bare re-skip keeps one. Refusals: activity_already_linked (that activity already tells another session's story, and the error names the blocker and the release path) and session_done (completions are permanent; fix a mis-link by re-completing, never by skip). Skipped ≠ silently open forever.
   • a REST day that happened: stride complete <id> --json with no activity id (rest has nothing to link; any other type still refuses without its activity, error code activity_required).
   • a WRONG LABEL on any session, done ones included: stride relabel <id> <type> "<detail>" ["<rationale>"] --json edits only the descriptive fields and returns {id, session_type, target_date, status}: the same id echoed, with status untouched as proof the edit was cosmetic (links and metrics never move; omitting the rationale keeps the stored one). A common case is a swap of days: an activity completed against Saturday's session whose label still says Sunday's plan. Do NOT week add the same date to fix a label, because that inserts a duplicate row you then have to skip. Refuses unknown ids (session_not_found) and non-numeric ids (bad_id), like complete/skip. One label IS behavioral, on any status: rest decides whether a bare complete needs an activity id. That path checks the label, not the status, so relabeling to or from rest changes what a completion (or re-completion) will demand.

Reading decoupling and detected structure

• Aerobic decoupling (decoupling_pct + decoupling_known on activity and every progress session row; decoupling_signal = "power", "pace" (grade-adjusted), or "speed" (no altitude stream, terrain NOT normalized, read cautiously on hilly routes)): second-half vs first-half efficiency drift. LOWER is better; ≤ +5% on a steady 1h+ effort = solid durability. Only meaningful on STEADY sessions. On intervals it reflects workout shape (check segments: when work reps are present, don't read drift as durability). Unknown when: no usable signal, the signal covers less than half the session, or |value| > 50% (artifact).
• W′ balance (activity.w_prime_balance): min_j is the lowest the anaerobic tank got during the ride and end_j is where it finished. Both read against the CP fit for that session's OWN sport family (fit_family) from the 90 days STRICTLY BEFORE it, so a session is never inside its own fit (cp_used/w_prime_used/fit_points). min_j: 0 means it emptied exactly. A NEGATIVE min_j is the model failing, not depth achieved. It means more above-CP work was done than the fitted tank holds, so the CP/W′ is stale or degenerate. model_exceeded: true flags exactly that, and |min_j| / w_prime_used is how badly. Report it as evidence the fit needs refreshing, NEVER as "how deep they went". Normalize by w_prime_used before comparing sessions. The fitted capacity moves between dates, so raw joules are not comparable. When model_exceeded is true, ONLY min_j means anything: the recovery term drives on the deficit against the CURRENT balance, so a balance far below zero refills faster than the model's own ceiling allows. end_j is then arithmetic on a broken premise. fit_r2 grades the fit itself. CP jumps at the window edges as rides enter and leave the 90 days, so these are WITHIN-session measures, not a comparable series. known: false means there was no fit or no power stream. Never read it as "the tank stayed full".
• Rep-level progression (stride reps --json): whether the SAME workout shape is being ridden harder than it used to be, shown as per-rep watts across sessions and the within-session fade. Use it when a structured session repeats; progress when comparing whole sessions.
• Detected structure (stride activity <id> --json): interval_summary ("3×[12:00 @ 230W / 4:00 easy]"; a pace-routed sport reads as time-per-distance, for example "5×[4:00 @ 4:00/km / 2:00 easy]", and the payload is ALWAYS metric whatever units is set to. The human screen follows the setting; this field does not), segments (per-rep kind/duration/avg + HR peak/avg/60s recovery drop), hr_drift + hr_drift_known (rising across reps = fatigue), and detection_attempted (false = couldn't look, meaning no power/pace signal, which is NOT the same as "verified: no structure"). The detector reports; matching structure to a prescription stays YOUR judgment.

Output modes

PASS --json ON EVERY QUERY YOU RUN. Stride prints human tables by default and machine JSON only when asked. Nothing infers the mode from your environment, so a command without the flag gives you a table no matter what your harness exports. The flag works in any argv position and the last one wins; --human forces tables even for you. STRIDE_FORMAT=json|human (case-insensitive) sets a shell-session default and the flag beats it. Note each shell command you run is typically a FRESH shell, so exporting it does not reliably carry between calls. --json is the one route that always works. -- ends flag parsing, so stride skip 5 --json -- --json stores the literal string as the reason and still returns JSON. Note the flag is present BEFORE the terminator, because -- stops flag parsing for everything after it. If output ever looks like a table when you wanted data, you left --json off. Every machine response you will consume is a versioned envelope, including usage errors ({"error":{"code":"usage",…}}) and a bare stride --json, which answers with the command table rather than the human help screen (#180). That table DESCRIBES rather than names (#219): one entry per callable form, each carrying {name, args:[{name,required,example}], mutates, network, interactive, schema}. week and week add are separate entries, because one reads and one writes. So you can determine argument shape, whether a call writes, whether it needs Strava, and which file under schemas/v3 the answer validates against, without reading this document. interactive: true marks the one form you must never call unattended (auth). Prefer that table over anything written here if the two ever disagree. The table is cross-checked against the parser in CI, and this file is not. It is hand-written, not generated: the verb set, the schema names, mutates, network and interactive are each checked against the source or against behaviour, while the free placeholder TEXT (<days> versus <limit>) is declared. Literal argument names, both arity bounds, and the rule that required arguments come first are all checked against the parser. One thing is NOT enveloped: stride auth, an interactive browser flow you run by hand. stride sync narrates progress on stderr while it runs. Its stdout is the envelope, so you can read it (#218, #232). Platform failures ARE enveloped now (#183): no_database (absent, run init), unreadable_database (present but unopenable, from permissions or a directory in its place, which init will NOT fix), corrupt_database, database_error (SQLite refused the operation, e.g. a lock), network_unreachable (Strava never answered), strava_error / rate_limited (it answered with a status), stdin_closed, and internal_error for anything unforeseen, carrying the clipped tag in its message. A failure without a code is therefore a bug, not a shrug. An expired token still arrives as not_authenticated, from the boundary as well as from sync. Success looks like {"schema_version":3,"data":{…}}, and error looks like {"schema_version":3,"error":{"code":"…","message":"…"}}. The payloads described in the table below all live under .data. Every payload here (every query, every action you branch on, the command list and the envelope itself, one file per published payload in schemas/v3/, so the directory listing is the inventory) is described formally in schemas/v3/*.json in the repo (required keys, types, enums, and the error-code vocabulary, which is diffed against the source in CI so a code stride can emit cannot be missing from the contract). error is an OBJECT whose code carries the in-band error names used throughout this file (unknown_command, missing_config, not_authenticated, derived_key, …), with the human text nested in error.message. An error envelope is ALSO an exit status: stride exits 1 whenever it emits one (0 on success; a bare stride prints help and exits 0). Read either channel; the two never disagree. rate_limited is the one code that appears on both sides (#227): as an ERROR code it means the command made no progress and exits 1; as sync's stopped value it means the drain did real work before Strava capped it, so it is a success envelope at exit 0 with resumable telling you whether anything is still missing. Discriminate on the envelope shape, never on the token. sync and analyze emit JSON results too ({synced, new_activities, updated_activities, pruned, streams_fetched, streams_skipped, pending_streams, stopped, resumable} / {computed, stream_errors, form_tsb, form_tsb_known, form_state, form_delta_7d, form_delta_known, converged}), and stride config get <key> --json emits {key, value} (or the not_set error envelope). That call is how you read timezone back, which governs what "today" means for every date below. stride config unset <key> --json REMOVES a stored key, emitting {key, removed}. removed: false means it was already absent, which is not an error. Use it rather than config set <key> "". An empty value is refused for every key class, because it used to mean three different things depending on the key. Two of those left no way to remove a row at all (a per-sport zone override could not be dropped, and an empty write to a token left a row reading as SET). stride config set units imperial switches HUMAN distance and pace readouts to miles and min/mi; metric is the default. It covers distances and pace columns, NOT the raw m/s rate shown for detected intervals on a pace-routed sport (#351). It does not change JSON at all. Every payload stays SI, so distance_m is metres and stats' km is kilometres whatever the setting says. If the athlete mentions miles, that is a display preference, not a change to the numbers you read.

Query commands (add --json to every one of these)

Conventions & gotchas

• Training weeks run Monday to Sunday by default. Plan and present weeks with Monday first; when computing day-of-week from dates, verify against a known anchor (2026-07-27 was a Monday).
• The window's game layer is display-only. No command surfaces it, so know the rules when the athlete asks. Athlete LEVEL comes from career hours across every sport (reaching level L costs 5·L·(L+1) cumulative hours, so each level costs ten hours more than the last; tiers every ten levels: rookie / grinder / engine / machine / legend). The hours are the same career totals stats reports, so you can derive the level and the hours to the next level yourself. The STREAK is consecutive Mon to Sun weeks with any load, every sport counting, and a loadless week still in progress does not break it. The plan view's quest pips are the week's done/total from the plan bundle. Gold celebrations fire for a ride power record set in the last seven days (power view) and for any family whose threshold peak IS the current month (career view). None of this is steerable over the bus, and none of it appears in any --json payload. It lives in the window, documented in docs/viz.md.
• Missing-value contract (ADR 0009): JSON null is not expressible (encoder stringifies tags), so absence is flagged, not nulled. Impossible-zero fields (np_w, avg_hr, intensity, ftp_used): 0 = not available. activity, activities, and plan.recent_activities_14d rows carry power_known/intensity_known/hr_known/zones_known + load_model; top rows carry the first three (they are separate flags because np can exist while intensity does not: power stream, no FTP yet). tss: 0 is AMBIGUOUS, so read load_model: ""/"none" = unscored, anything else = a scored near-zero effort. Zone seconds z1_s..z5_s mean their 0 literally ONLY when zones_known: true; all-zero with zones_known: false = no HR stream (summary avg_hr can exist without one, and hr_known does not cover zones). distance_m 0 is always literal. Fields that are BOTH possible-zero and possibly-absent carry a _known flag (decoupling_known, form_delta_known, hr_drift_known, rec_drop_known, and form_tsb_known in analyze). Trust the flag, never the magnitude. The rule is PER PAYLOAD, not per field name: summary ships form_tsb bare because it is always computable there. Read the schema for the command. progress sessions carry only decoupling_known and no other flag on purpose: rows exist only because the group lens scored them.
• Zone seconds are HR-based (universal across sports). Power feeds TSS/NP, and pace feeds the intensity split for any DISTANCE sport without power (a pool swim qualifies, since only a distance stream is needed, not GPS or altitude).
• Load ladder for ENDURANCE sports: stream-NP → Strava weighted watts → avg watts → pace (rtss) → hrTSS (zone-weighted) → avg-HR → session-RPE → relative_effort. Strength-class sports rank session-RPE ABOVE heart rate (Sports.class, ADR 0003), because the athlete is the better sensor there. The ladder is a mixed model, not "TSS"; load_model on each row records which rung scored it.
• FTP is DERIVED, never configured. Per sport, per activity era: best 20-min power × 0.95 over the 60 days up to each activity (summary.ftp = {best_20min_w_60d, estimated_ftp_w} for rides). The ftp / ftp_<sport> config keys are REFUSED with error code derived_key. There is nothing to fix when FTP moves; INTERPRET the trajectory instead (a rising estimated_ftp_w is fitness, a falling one is detraining or a power-data gap; check doctor coverage before concluding).
• Metric recompute triggers (what invalidates metrics): derived-FTP change (metrics store ftp_used), derived threshold-pace change (threshold_pace_used, the pace analog, keyed per sport), HR-zone change, stream arrival, rating change, and activity-input edits (analyze compares each row's stored inputs; sync itself never deletes metrics). So after a sync, always analyze to pick up recomputes.
• CTL/ATL/TSB are as of today (daily_load extends through today with 0-TSS rest days), so form_tsb is current, with no mental decay adjustments needed. "Today" is the LOCAL day, anchored by config timezone (IANA, e.g. America/Chicago, DST-correct automatically; preferred) or a fixed utc_offset_minutes fallback (e.g. -300); precedence is timezone > offset > UTC. Without either, users west of UTC get a phantom "tomorrow" row each evening. doctor shows which anchor is active.
• Session-RPE: after a strength/HIIT/yoga session, ask the user how hard it felt (1-10) and run stride rate <activity_id|latest> <n> --json. Load = hours × RPE × 10 (on the same scale as TSS). For strength-class sports the rating outranks HR in the load ladder; for endurance, measured power/HR outrank it. Rating an activity invalidates its metrics (re-analyze rescores). Ratings live in their own table and survive re-syncs.
• Junk HR (outside 35 to 220 bpm) is filtered at analyze time for stream SAMPLES, so sessions with bad straps (common on Peloton strength workouts) get near-0 TSS. That result is honest "no data", not zero effort. Weigh strength by session count, not TSS. avg_hr in activities output is raw (unfiltered).
• The same 35 to 220 bound is applied again at REPORT time by four consumers, each with a different consequence. TWO of them apply it to avg_hr_scored: the mean of the session's in-band HR stream when the surviving samples span at least half the LONGER of the stream's own extent and the session's moving time, and the stored average otherwise (#311). Those two are progress's lenses and activity's baselines.ef. The other two read the STORED avg_hr: top hr bounds that column by design (#315), and the load ladder's hr_avg rung reads it. That rung is reachable only when the stream yields no zone seconds, which FORCES avg_hr_stream to be NULL as well. The implication runs one way, not both: a stream can yield zone seconds and still be too short to produce a mean. Either way the ladder can never divide by a number that differs from avg_hr_scored. So a session whose stored reading is impossible can still be scored, from its stream, and one whose stream is a dead strap's first few minutes is refused even though its stored reading looks fine. progress, activity and activities all publish avg_hr_scored beside avg_hr (#319), so the divisor behind any EF verdict is readable rather than inferred. progress counts the refused session in hidden_lens and omits it from sessions[], while the HUMAN table still shows the row with its lens cells blank and the columns that never needed a heart rate filled (#286). The agent reads hidden_lens and the athlete sees the ride. activity publishes ef.known: false with ef.current: 0. The load ladder falls to its next rung and names it in load_model, so this one DOES change TSS. It is the consumer that propagates, into CTL, ATL and every form verdict. top hr does not rank the reading at all: it is absent from that list. Absence there is NO LONGER corroboration that a reading is broken, because top hr bounds the stored value while the lenses score the corrected one. A session the engine RESCUED (EF published, load scored from its stream) is missing from top hr too. Check avg_hr_scored rather than reading absence there. A refused reading's id is not recoverable from the JSON, and if every reading is out of band the list comes back EMPTY. {"data":[]} then reads as "never recorded a heart rate" for an athlete who has 672 of them. To find the broken sessions themselves use stride activities --json and look for an avg_hr_scored under 35 or over 220 AND hr_known: true. That field is the one the lenses divide by, and testing avg_hr instead stopped identifying refused rows the moment the engine began scoring from streams (a session can store 18 bpm and score fine). The hr_known half is what separates a broken reading from a session that simply never wore a strap: on the reference database 69 rows are out of band and only 3 of them recorded anything. Without it you report 23 times too many and tell the athlete to repair activities that need equipment instead. A LARGE gap between the two fields is a further signal (Strava computing its summary from a lossy stream), but any gap is not: 669 of 738 rows differ, almost all by a rounded decimal, while only 11 differ by more than 15 bpm. plan echoes the raw avg_hr only, and activity publishes it beside hr_known: true.
• created_at in planned sessions is an ISO datetime string (UTC, e.g. 2026-07-27T18:04:22Z).
• Streams are drained by sync until the read budget stops it; older activities gain zone data over repeated syncs. sqlite3 ~/.stride/db.sqlite "SELECT COUNT(*) FROM streams" shows progress.

Setup & credentials

Day-to-day: none. stride auth stores the Strava client id/secret and tokens in the db, and sync auto-refreshes. STRAVA_CLIENT_ID/STRAVA_CLIENT_SECRET env vars act as overrides if set. A locked/corrupt db surfaces as a real error, not a false "not authenticated".

First-time on a new machine: create a Strava API app (strava.com/settings/api), then stride init --json → STRAVA_CLIENT_ID=... STRAVA_CLIENT_SECRET=... stride auth (browser paste flow, interactive, the one command you run WITHOUT --json) → stride config set hr_z1_max..hr_z4_max --json (+ timezone, IANA) → stride sync --json → stride analyze --json. Each step's failure is an envelope you can branch on (not_authenticated, missing_config), which is the point of flagging a setup chain. The db self-migrates on any command, so upgrading the binary against an existing db is safe.

Development

just test is the single entry point (pure expects → fresh build → just e2e, the sandbox-HOME suite embedded in the justfile, and the same pipeline CI runs). The ordering matters: a failed build leaves a stale binary that the e2e suite would happily "pass" against, which is why just test builds in between.

Toolchain: Roc's new (Zig) compiler (one nightly, pinned as the default of .github/actions/setup-roc; no per-job overrides, and tools/pin-check.sh enforces it) + basic-cli 0.23 (the line named in src/main.roc's platform URL; e2e holds this sentence to that header) + builtin JSON (roc-json dropped). The full just test (expects, build, and e2e) runs green; the roc#10469 perf gate is fixed. Build flags take = (--output=, --main=) and always --opt=dev, since the optimized backend was miscompiling (issue #32, fixed on the 2026-08-17 pin; dev is now kept for build time). A Roc gotcha that keeps recurring: floats have no Eq, so never x == 0.0 in an expect; use (x).abs() < 0.001 (Num.abs does not exist). Compiler syntax/stdlib reference: docs/roc-new-compiler-notes.md.