From Ask Coach answers to reviewable training decisions

• Ask Coach can now prepare a one-session shortening proposal without changing the permanent programme.
• Proposal cards show the exact before-and-after prescription, with approval, undo, and use states.
• Coach responses carry issued evidence and response blocks instead of relying on whatever the model happened to retrieve.
• Contextual Coach entry points now appear across the plan, logger, workout, history, and summary surfaces.

Product: a coach should help you decide, not quietly decide for you

The useful question isn’t whether an AI can produce a plausible training answer. It’s whether an athlete can understand what that answer is based on, see exactly what will change, and decline it without losing control of the plan.

That distinction shaped this week’s Coach work. INCREMNT can open Coach from the places where a question naturally occurs: a programme, an exercise record, an active logger, a workout summary, or the main home surface. The entry point carries context rather than asking you to restate it. A question about a lift can start beside that lift. A question about today’s session can start beside the session.

The interface now makes a stronger distinction between an answer and an action. A Coach response can include a chart, a compact evidence block, a clarification, or a proposal. Those are different things, and they should look different. In particular, a proposal is not an edit. It is a candidate change waiting for review.

The first bounded action is deliberately modest: shorten one session on one date. Coach may remove a working set from selected exercises or omit an exercise, while preserving warm-ups and at least one exercise. The review card says “One session only”, names the date, and shows the before-and-after working-set counts. The permanent programme stays unchanged. You can apply the change, undo it before the workout, or leave it alone.

That scope matters on a busy week. “Make tomorrow shorter” is not the same request as “change my programme”. A temporary override should not become a hidden programme mutation simply because both requests mention volume. It also needs to survive the practical edges of training: relaunching the app, handing a workout to Apple Watch, or rejecting a Watch handoff. The override is date-scoped, stored locally, consumed once when the workout starts, and made available again if the handoff is rejected.

We also kept working on the quieter parts of trust. The equipment picker now groups common equipment, keeps bodyweight available, and tucks less common options behind a clear disclosure. Returning users get the same setup rules as new users. Programme generation preserves the intent behind the choices and the edits an athlete reviewed. These changes are less visible than a new Coach card, but they solve the same product problem: the system should remember what you meant.

Building INCREMNT: contracts before autonomy

The engineering change behind this shift is a bounded single-agent lane in the existing Coach stack. It is opt-in behind ASK_AGENT_FOUNDATION_ENABLED=true; the compatibility lane remains the default. That is an important status marker. We built a migration seam and the supporting evidence, not a claim that the new path is ready for every conversation.

The agent can choose read tools and select issued evidence or proposal IDs. The application still owns scope checks, chart construction, prescription compilation, and applying approved actions. There is no second model pass rewriting the final answer in this lane. Calls are bounded by a step count, tool count, abort signal, and elapsed-time budget.

The reason for those boundaries is visible in the failure modes we addressed. A routed year window could be lost in a fallback and turn a six-session query into a misleading “missing yearly data” answer. A valid record-qualified evidence reference could be rejected because verification expected a tool-level name. Candidate retries could share mutable provenance, leaving an earlier action attached to later prose. A model could invent a programme load or treat a temporary workout request as a permanent-plan edit. None of those failures is fixed by asking for nicer prose.

The foundation gives each turn a more durable shape. Evidence is registered with scope, source IDs, timestamps, missing-data flags, and bounded facts. A receipt identifies the final delivered text, cards, and actions. A generation revision links that delivery to the original agent bundle. If verification fails, the system cannot restore an earlier action or quietly promote confidence. Sparse charts report the records that actually exist instead of pretending the requested cohort was complete.

Programme creation follows the same principle. The model can select eligible exercise slots from the existing policy, but it cannot author numeric prescriptions or override starting loads. The app materializes and validates the draft. Named weekdays are mapped to the policy convention in code. An uncalibrated weighted lift carries a starting-load warning instead of a fabricated number. This is a useful division of labour: language models are good at interpreting intent; deterministic application code is better at enforcing what that intent is allowed to do.

The iOS side makes the proposal contract concrete. CoachSessionProposal carries a version, scope, date, programme identity, day index, summary, and exact prescriptions before and after each change. Resolution refuses stale dates, mismatched programme IDs, duplicate exercise targets, changed source prescriptions, empty resulting workouts, and unsupported operations. ProgramStore persists only valid overrides and refuses to overwrite another reviewed override for the same slot. Logger smart defaults cannot replace a reviewed prescription.

The tests are not decorative coverage. They exercise date scope, persistence, idempotent approval, undo, consumption, and Watch rollback. The CLI tests cover bounded tool calls, evidence references, retry invalidation, proposal integrity, chart delivery, and policy-based drafts. A replay script runs the generator in-process without starting the production conversation route or saving athlete memory. That makes failures reproducible without confusing a local experiment for a deployed result.

There is a trade-off here. A stricter contract can make Coach answer “I need one more detail” more often, and a bounded agent can feel less magical than an unconstrained one. I prefer that friction to an impressive answer attached to the wrong records or an unreviewed plan change. The product earns autonomy one observable boundary at a time.

Also moved forward

• Exercise history now shows dates and uses a unified filter path, making comparisons easier to audit.
• Workout and Watch lifecycle fixes add cancellation diagnostics, recover timed-out cleanup, and preserve workouts through mirror delays.
• Coach response blocks now support typed content, semantic work timelines, guided clarification answers, and evidence-native progress blocks.
• Release tooling was prepared with guarded TestFlight orchestration and clearer terminal failure reporting; this is preparation, not proof of a shipped release.

What’s next

The foundation stays behind its flag until repeated production-derived replays, native review/apply/undo visual QA, Watch confirmation, and an end-to-end canary through the deployed HTTP route all pass. Temporary substitutions, ordering changes, load changes, and multi-day adaptation are intentionally not part of the first session proposal. The next step is to prove the narrow lane in the real route before widening what Coach is allowed to do.