[HugoFara]

Step 2 of the sync build order, plus a real Anki to test against. The sync page now works both ways, and the whole loop is verified against Anki 26.9.3 with AnkiConnect, with FSRS on and off.

Anki in a container: scripts/anki/container

• What it is: headless Anki (Qt offscreen) with AnkiConnect, built from first-party sources only. Anki comes from PyPI (aqt[qt6]==26.9.3, published by Ankitects); AnkiConnect comes from AnkiWeb, checked against a pinned SHA-256.
• Startup: a start script creates the profile through Anki's own ProfileManager, so no first-run dialog blocks. ANKI_FSRS=1 or 0 chooses the scheduler.
• Config: AnkiConnect trusts LWT's dev-server origins and binds inside the container. The run command publishes it on loopback only.
• Commands: npm run anki:build, anki:up and anki:down, all with Podman. The exchange folder cypress/anki-exchange/ is git-ignored.

Step 2: LWT → Anki

After the pull (step 1), the page sends each card's revlog to POST /api/v1/anki/push-plan. AnkiPushPlan answers with:

• Missing reviews: insertReviews rows for LWT reviews the card's revlog lacks, shaped exactly like ApkgWriter's rows. Ids clashing with Anki's are stepped past, because one clash fails the whole batch.
• Per-card schedule: the due date (setDueDate), plus interval, reps and lapses (setSpecificValueOfCard with warning_check, batched through multi, checking each reply).

Cards Anki already has everything for get no action, so a sync right after another changes nothing either way.

What real Anki showed

Measured with a twin-card experiment, and in AnkiConnect's source:

• insertReviews only appends history. The card's interval, due date, reps, lapses and FSRS stability are untouched. Anki's next answer is identical to that of a twin card without the insert, so the schedule has to be set explicitly.
• FSRS memory state can't be written. AnkiConnect refuses it ("Coupled scheduler state must use native scheduling transitions"). With FSRS on, Anki's estimate catches up when the learner reoptimises, and the due dates are right regardless. The page says so.
• setDueDate adds a grade-less "rescheduled" revlog row, which the pull already ignores.

These answer the spike's open questions. The doc is updated, with a "Testing against real Anki" section.

Tests

• 24-anki-live.cy.ts: export terms from LWT, importPackage into Anki, answerCards (Good, Again, Easy), sync, answer one term in LWT, sync again. It then checks Anki has both answers and LWT's interval and reps on the card, and that a third sync does nothing in either direction.
  • Passes with FSRS off and on, including repeated cold starts.
  • It skips itself when nothing answers on 8765, so CI is unaffected.
• Unit tests:
  • AnkiPushPlanTest (7): row shape, card schedule, only missing reviews, an up-to-date card, an id collision, skips, a never-reviewed term.
  • Frontend anki_sync.test.ts: the push order and grouping, a refused card value, and the batched plan.
• Gates: composer test:no-coverage (9220), npm test (4440), Psalm (no errors), phpcs, lint, build:all and docs:build all pass. 21 to 23 still pass, and check-locales reports 100% for all 11 locales (the page text changed from "pull" to "sync").

Step 3 (fields, tags, flags, existence through the sync base) is not in this PR, so #264 stays open.

🤖 Generated with Claude Code