Release ledger

What's new in SimDeck

A version-by-version record of approved SimDeck improvements.

Version 0.55

July 16, 2026

Student card actions recheck safety and policy at commit time

Student use, direct sends, and approval-required send requests now repeat every safety, participant, and card-policy prerequisite inside the atomic write, so a stale page cannot outrun David's latest classroom controls.

Why it matters

- A simulation lock or disabled student action takes effect before the next card write, even when a student submitted from an older open page.
- Changing send approval mode cannot let an in-flight action take the old direct-send or request path.
- A removed classmate, changed student access, or newly restricted card route stops the action before either the card or Activity history changes.

Verification

- All 480 unit tests pass across 48 files, including stale game safety, approval mode, and template routing decisions.
- Critical-source coverage passes at 85.39% statements, 72.50% branches, 96.17% functions, and 94.45% lines; actions remain at 94.98% line coverage.
- Typecheck, zero-warning source and static-security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.55 draft remains on PI-213 until the exact commit receives staging proof; the canonical ledger follows that proof.

Source: Linear release ledger document, PI-213

Repeated current game safety, acting-student eligibility, optional recipient eligibility, and template policy reads through each student action transaction.
Required approval mode to match the path selected before the transaction, aborting when David changes that setting during submission.
Added game, student owner, and original template identifiers to the exact card compare-and-set guards for use, send, and request reservation.
Covered transaction-time game-lock, approval-mode, and routing-policy drift with focused no-partial-write regressions.

Version 0.54

July 16, 2026

Send approvals recheck every prerequisite inside the transaction

Teacher approval now repeats sender, recipient, same-game, and card-policy checks inside the atomic decision, so participant or policy drift cannot move the card or close the request.

Why it matters

- David cannot approve a send after its requesting student or classmate recipient became ineligible, even if the approval page still shows the older state.
- A student moved to another class or a changed card-template destination rule stops approval before either the card or pending request is mutated.
- A valid approval still moves the exact card version and closes the exact unresolved request together in one Appwrite transaction.

Verification

- All 477 unit tests pass across 48 files, including sender, recipient, relationship, and policy drift after preflight plus successful transactional approval.
- Critical-source coverage passes at 85.73% statements, 72.97% branches, 96.17% functions, and 94.68% lines; actions remain at 95.46% line coverage.
- All 465 public smoke and accessibility cases pass across Chromium, Firefox, WebKit, Mobile Chrome, and Mobile Safari; the five credential-gated teacher cases skip as designed.
- The complete live pending-send decision verifier and full production integrity audit pass without classroom or Auth writes.
- Typecheck, full lint, zero-warning static security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.54 draft was recorded on PI-213 before this public page entry; the canonical ledger follows exact staging proof.

Source: Linear release ledger document, PI-213

Repeated current requesting-student, optional classmate-recipient, and card-template reads through the same transaction used for the approval writes.
Required exact same-game relationships and current student eligibility before the first mutation in that transaction.
Reapplied the template's destination policy to the current recipient and added the original card-template id to the card compare-and-set guard.
Expanded the production pending-send verifier to classify every current decision from live student, card, request, and template records without writing classroom data.

Version 0.53

July 16, 2026

Every Activity link is checked before history is written

SimDeck now enforces one same-game relationship rule at the central Activity writer, so no action can attach an orphan or cross-class card or student to classroom history.

Why it matters

- David's Activity history cannot gain a false card or student link because one caller forgot to repeat a relationship check.
- Atomic card actions validate new or updated rows through the same Appwrite transaction before the history row is inserted.
- Intentionally unlinked safety history remains valid, including blocked attempts whose optional card could not be trusted.

Verification

- All 472 unit tests pass across 48 files, including valid, intentionally unlinked, orphan, cross-game, transactional, rollback, and copied-reference cases.
- Critical-source coverage passes at 85.71% statements, 72.85% branches, 96.17% functions, and 94.70% lines; the new relationship guard is included in the protected set and actions remain at 95.50% line coverage.
- All 465 public smoke and accessibility cases pass across Chromium, Firefox, WebKit, Mobile Chrome, and Mobile Safari; the five credential-gated teacher cases skip as designed.
- The complete live Activity relationship verifier and full production integrity audit pass without classroom or Auth writes.
- Typecheck, full lint, zero-warning static security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.53 draft was recorded on PI-213 before this public page entry; the canonical ledger follows exact staging proof.

Source: Linear release ledger document, PI-213

Added one central relationship guard to the Activity insertion path for every optional card and student reference.
Scopes relationship reads by id and game and also checks the returned game defensively before allowing the insert.
Uses the caller's active Appwrite client so staged card creation or updates are visible and any validation failure rolls back the whole classroom action.
Added complete read-only production proof across every live Activity row, not only selected action types.

Version 0.52

July 16, 2026

Blocked attempts cannot forge card history

When student use or sending is disabled, SimDeck now attaches a card to the blocked-attempt Activity row only after proving it is that student's active card in the same game.

Why it matters

- A crafted blocked action cannot create an orphan or cross-class card link in David's Activity history.
- Normal blocked attempts still retain useful card context when the submitted card is genuinely the student's active card.
- Missing, moved, inactive, cross-game, or lookup-failed cards still produce the established safety feedback without making a false relationship claim.

Verification

- All 465 unit tests pass across 46 files, including valid, forged or missing, and lookup-failed card references for both blocked student use and blocked student send.
- Critical-source coverage passes at 85.69% statements, 72.68% branches, 96.16% functions, and 94.69% lines; actions reach 95.50% line coverage.
- All 465 public smoke and accessibility cases pass across Chromium, Firefox, WebKit, Mobile Chrome, and Mobile Safari; the five credential-gated teacher cases skip as designed.
- The live read-only blocked-Activity verifier and full production integrity audit pass without classroom or Auth writes.
- Typecheck, full lint, zero-warning static security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.52 draft was recorded on PI-213 before this public page entry; the canonical ledger follows exact staging proof.

Source: Linear release ledger document, PI-213

Added one optional card lookup scoped by card, game, current student, student ownership, and active status before blocked-attempt logging.
Stores a null card relationship when verification does not succeed and never copies the raw submitted card ID into metadata.
Marks new blocked rows with whether their optional card relationship was verified while remaining compatible with existing history.
Added a focused read-only production invariant for blocked use/send Activity relationships and marker consistency.

Student card actions recheck safety and policy at commit time

Why it matters

- A simulation lock or disabled student action takes effect before the next card write, even when a student submitted from an older open page.
- Changing send approval mode cannot let an in-flight action take the old direct-send or request path.
- A removed classmate, changed student access, or newly restricted card route stops the action before either the card or Activity history changes.

Verification

- All 480 unit tests pass across 48 files, including stale game safety, approval mode, and template routing decisions.
- Critical-source coverage passes at 85.39% statements, 72.50% branches, 96.17% functions, and 94.45% lines; actions remain at 94.98% line coverage.
- Typecheck, zero-warning source and static-security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.55 draft remains on PI-213 until the exact commit receives staging proof; the canonical ledger follows that proof.

Source: Linear release ledger document, PI-213

Repeated current game safety, acting-student eligibility, optional recipient eligibility, and template policy reads through each student action transaction.

Required approval mode to match the path selected before the transaction, aborting when David changes that setting during submission.

Added game, student owner, and original template identifiers to the exact card compare-and-set guards for use, send, and request reservation.

Covered transaction-time game-lock, approval-mode, and routing-policy drift with focused no-partial-write regressions.

Send approvals recheck every prerequisite inside the transaction

Teacher approval now repeats sender, recipient, same-game, and card-policy checks inside the atomic decision, so participant or policy drift cannot move the card or close the request.

Why it matters

- David cannot approve a send after its requesting student or classmate recipient became ineligible, even if the approval page still shows the older state.
- A student moved to another class or a changed card-template destination rule stops approval before either the card or pending request is mutated.
- A valid approval still moves the exact card version and closes the exact unresolved request together in one Appwrite transaction.

Verification

- All 477 unit tests pass across 48 files, including sender, recipient, relationship, and policy drift after preflight plus successful transactional approval.
- Critical-source coverage passes at 85.73% statements, 72.97% branches, 96.17% functions, and 94.68% lines; actions remain at 95.46% line coverage.
- All 465 public smoke and accessibility cases pass across Chromium, Firefox, WebKit, Mobile Chrome, and Mobile Safari; the five credential-gated teacher cases skip as designed.
- The complete live pending-send decision verifier and full production integrity audit pass without classroom or Auth writes.
- Typecheck, full lint, zero-warning static security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.54 draft was recorded on PI-213 before this public page entry; the canonical ledger follows exact staging proof.

Source: Linear release ledger document, PI-213

Repeated current requesting-student, optional classmate-recipient, and card-template reads through the same transaction used for the approval writes.

Required exact same-game relationships and current student eligibility before the first mutation in that transaction.

Reapplied the template's destination policy to the current recipient and added the original card-template id to the card compare-and-set guard.

Expanded the production pending-send verifier to classify every current decision from live student, card, request, and template records without writing classroom data.

Every Activity link is checked before history is written

SimDeck now enforces one same-game relationship rule at the central Activity writer, so no action can attach an orphan or cross-class card or student to classroom history.

Why it matters

- David's Activity history cannot gain a false card or student link because one caller forgot to repeat a relationship check.
- Atomic card actions validate new or updated rows through the same Appwrite transaction before the history row is inserted.
- Intentionally unlinked safety history remains valid, including blocked attempts whose optional card could not be trusted.

Verification

- All 472 unit tests pass across 48 files, including valid, intentionally unlinked, orphan, cross-game, transactional, rollback, and copied-reference cases.
- Critical-source coverage passes at 85.71% statements, 72.85% branches, 96.17% functions, and 94.70% lines; the new relationship guard is included in the protected set and actions remain at 95.50% line coverage.
- All 465 public smoke and accessibility cases pass across Chromium, Firefox, WebKit, Mobile Chrome, and Mobile Safari; the five credential-gated teacher cases skip as designed.
- The complete live Activity relationship verifier and full production integrity audit pass without classroom or Auth writes.
- Typecheck, full lint, zero-warning static security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.53 draft was recorded on PI-213 before this public page entry; the canonical ledger follows exact staging proof.

Source: Linear release ledger document, PI-213

Added one central relationship guard to the Activity insertion path for every optional card and student reference.

Scopes relationship reads by id and game and also checks the returned game defensively before allowing the insert.

Uses the caller's active Appwrite client so staged card creation or updates are visible and any validation failure rolls back the whole classroom action.

Added complete read-only production proof across every live Activity row, not only selected action types.

Blocked attempts cannot forge card history

When student use or sending is disabled, SimDeck now attaches a card to the blocked-attempt Activity row only after proving it is that student's active card in the same game.

Why it matters

- A crafted blocked action cannot create an orphan or cross-class card link in David's Activity history.
- Normal blocked attempts still retain useful card context when the submitted card is genuinely the student's active card.
- Missing, moved, inactive, cross-game, or lookup-failed cards still produce the established safety feedback without making a false relationship claim.

Verification

- All 465 unit tests pass across 46 files, including valid, forged or missing, and lookup-failed card references for both blocked student use and blocked student send.
- Critical-source coverage passes at 85.69% statements, 72.68% branches, 96.16% functions, and 94.69% lines; actions reach 95.50% line coverage.
- All 465 public smoke and accessibility cases pass across Chromium, Firefox, WebKit, Mobile Chrome, and Mobile Safari; the five credential-gated teacher cases skip as designed.
- The live read-only blocked-Activity verifier and full production integrity audit pass without classroom or Auth writes.
- Typecheck, full lint, zero-warning static security lint, production build, backendless demo, 10 skeleton states, theme contrast, npm audit with zero vulnerabilities, and git diff validation pass.
- The Version 0.52 draft was recorded on PI-213 before this public page entry; the canonical ledger follows exact staging proof.

Source: Linear release ledger document, PI-213

Added one optional card lookup scoped by card, game, current student, student ownership, and active status before blocked-attempt logging.

Stores a null card relationship when verification does not succeed and never copies the raw submitted card ID into metadata.

Marks new blocked rows with whether their optional card relationship was verified while remaining compatible with existing history.

Added a focused read-only production invariant for blocked use/send Activity relationships and marker consistency.