Cardecky — föderierte Spaced-Repetition-App des Vereins mana e.V.
Find a file
Till JS d45f1c0079 Phase 12 R3: Marketplace γ + δ — Discovery + Engagement + Subscribe + Smart-Merge
Routes (additiv unter /api/v1/marketplace/*):

Discovery (optional-auth, anonymer Read erlaubt):
- GET /explore — featured + trending side-by-side
- GET /decks — browse mit q/tag/language/author/sort/limit/offset
  (sort: recent | popular | trending; trending = star-velocity 7d)
- GET /tags — flacher Tag-Tree

Engagement (auth pro Schreib-Route, optional-auth für GET state):
- POST/DELETE/GET /decks/:slug/star
- POST/DELETE/GET /authors/:slug/follow (cannot-follow-self → 409)

Subscribe + Version-Read + Smart-Merge-Diff:
- POST/DELETE/GET /decks/:slug/subscribe
- GET /me/subscriptions (mit update_available-Indicator)
- GET /decks/:slug/versions/:semver — voller Cards-Payload in ord-
  Reihenfolge
- GET /decks/:slug/diff?from=:semver — computeDiff (added/changed/
  removed/unchanged) basierend auf content_hash + ord-Heuristik für
  "changed an gleicher Position"

Fork + Smart-Merge-Pull (auth):
- POST /decks/:slug/fork — kopiert latest version in privaten
  cards.decks (forked_from_marketplace_* gesetzt) + cards.cards mit
  übernommenem content_hash + frische FSRS-Reviews
- POST /private/:deckId/pull-update — Smart-Merge: existing private
  hashes deduplizieren, nur added/changed cards einfügen (mit fresh
  reviews), unveränderte Karten BEHALTEN inkl. FSRS-State, removed
  cards bleiben lokal (server-authoritative User-Choice). Update der
  forked_from_marketplace_version_id auf latest.

Schema (R3a):
- cards.decks: 2 neue Columns forked_from_marketplace_deck_id +
  forked_from_marketplace_version_id (text, nullable). Drizzle-push
  grün.

Architektur-Highlights:
- @cards/domain.cardContentHash ist die single source of truth für
  Karten-Hashing; marketplace.deck_cards und cards.cards berechnen
  identisch → Smart-Merge ist hash-equality + INSERT-IGNORE statt
  Diff-Replay
- pgSchema-Trennung (marketplace.* vs. cards.*) zahlt sich aus:
  Marketplace-Read-Path (Public + Engagement) und privater Lern-Pfad
  haben separate FK-Welten und können unabhängig versioniert werden
- Hono-Middleware-Pattern: per-route authMiddleware/optionalAuth statt
  Sub-Router-Mount, weil ein Wildcard '*' auf einem Sub-Router via
  r.route('/', sub) sonst die Public-GET-Routes des Parents fängt
  (Hono-Routing-Subtilität, kostete eine Smoke-Iteration)

Verifikation:
- type-check 0 errors
- 6 neue Diff-Heuristik-Tests, 78 gesamt grün
- End-to-End-Smoke gegen lokale cards-api:
  · Cardecky-Author + Deck `r3-stoische-grundbegriffe` v1.0.0 (3 Karten)
  · Till browst (anon → 200), starred, folgt Cardecky, subscribed
  · Till forkt → privates Deck mit 3 Karten + 3 fresh FSRS-Reviews
  · SQL-Manipulation: Apatheia-Review auf state='review',
    stability=10, reps=3 (simuliert "schon gelernt")
  · Cardecky publisht v1.1.0: Apatheia + Eudaimonia unverändert,
    Logos präzisiert (changed), Tugendlehre neu (added)
  · Diff-Endpoint zeigt: unchanged=2, changed=1, added=1, removed=0
  · Till pull-update → cards_inserted=2 (changed.next + added)
  · Verifikation: card_count=5 (war 3), Apatheia-Review **identisch
    erhalten** (state=review, stability=10, reps=3, last_review IS
    NOT NULL), neue Karten state=new — FSRS-State der unveränderten
    Karte überlebt Smart-Merge unverletzt

Verbleibend: R4 ε (PRs + Card-Discussions), R5 Frontend-Routes
(/explore, /d/[slug], /u/[slug], /me/subscribed, /me/forks), R6
voller UI-E2E.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 15:27:39 +02:00
.github/workflows Phase 0+1: Repo-Skelett für Cards-Greenfield 2026-05-08 14:08:41 +02:00
apps Phase 12 R3: Marketplace γ + δ — Discovery + Engagement + Subscribe + Smart-Merge 2026-05-09 15:27:39 +02:00
docs Phase 12 R2: Marketplace-Backend α + β — Authors + Deck-Init + Publish 2026-05-09 15:13:58 +02:00
infrastructure fix(web): SvelteKit-env via \$env/dynamic/public statt import.meta.env 2026-05-08 22:03:35 +02:00
packages/cards-domain Phase 9l: Image-Occlusion als 4. MVP-CardType 2026-05-08 18:50:45 +02:00
.env.example Phase 5: Föderations-Endpunkte — Cards ist föderierter Peer 2026-05-08 17:10:35 +02:00
.gitignore Phase 10a: Production-Deploy-Stack (Mac Mini) 2026-05-08 20:09:19 +02:00
.npmrc Phase 9d: Pre-Flight — Protocol-Mirror durch upstream ersetzt 2026-05-08 18:00:56 +02:00
.prettierrc.json Phase 0+1: Repo-Skelett für Cards-Greenfield 2026-05-08 14:08:41 +02:00
app-manifest.json Phase 9d: Pre-Flight — Protocol-Mirror durch upstream ersetzt 2026-05-08 18:00:56 +02:00
CLAUDE.md Phase 12 R0+R1: Marketplace-Restore-Plan + Schema in marketplace-pgSchema 2026-05-09 15:05:22 +02:00
package.json dev: dev:full + cards-dev-Alias + lokale mana-auth-Pipeline 2026-05-09 12:38:51 +02:00
pnpm-lock.yaml dev: dev:full + cards-dev-Alias + lokale mana-auth-Pipeline 2026-05-09 12:38:51 +02:00
pnpm-workspace.yaml Phase 0+1: Repo-Skelett für Cards-Greenfield 2026-05-08 14:08:41 +02:00
README.md dev: dev:full + cards-dev-Alias + lokale mana-auth-Pipeline 2026-05-09 12:38:51 +02:00
STATUS.md Phase 12 R3: Marketplace γ + δ — Discovery + Engagement + Subscribe + Smart-Merge 2026-05-09 15:27:39 +02:00
tsconfig.base.json Phase 3 follow-up: type-check + tests grün, ts-fsrs v5 API 2026-05-08 14:41:04 +02:00
turbo.json Phase 0+1: Repo-Skelett für Cards-Greenfield 2026-05-08 14:08:41 +02:00

Cards

Eigenständige Spaced-Repetition-App des Vereins mana e.V.

Cards ist eine föderierte Peer-App im mana-Ökosystem. Sie verwaltet Karteikarten, plant Wiederholungen mit dem FSRS-Algorithmus und empfängt Inhalte aus anderen Verein-Apps (z.B. Zitate aus Memoro, Notizen aus Mana, Web-Schnipsel aus dem Browser-Plugin).

→ Live (geplant): https://cardecky.mana.how

Aktueller Stand und Pickup-Onboarding: STATUS.md.

Stack

  • Frontend: SvelteKit 2 + Svelte 5 (runes-only)
  • Backend: Hono + Bun + Drizzle ORM
  • Datenbank: Postgres mit Schema-Isolation (pgSchema('cards'))
  • Auth: föderiert über mana-auth (EdDSA JWT, JWKS-Cache)
  • Subscriptions: mana-credits (zentral pro Verein-Account)
  • AI-Tools: über mana-mcp Claude Desktop / persona-runner verfügbar
  • i18n: DE / EN / FR / ES / IT
  • Build: Turborepo + pnpm 9

Status

Phase 0 (Repo-Skeleton) — siehe mana/docs/playbooks/CARDS_GREENFIELD.md für den vollständigen Plan.

Lokal entwickeln

pnpm install
pnpm dev:full           # cards docker + mana docker + DB-Push (cards & auth) + dev (cards & mana-auth)

Oder von überall via zsh-Alias: cards-dev.

dev:full greift in ../mana/ (Plattform-Repo): startet mana-postgres, pushed mana-auth-Schema, und startet mana-auth auf :3001 parallel zu cards-api/-web. Damit ist Login lokal komplett testbar (Cookie-Domain localhost, eigener Dev-User in lokaler mana_auth-DB).

Einzelschritte (falls nur Teile gebraucht werden):

pnpm docker:up          # Cards Postgres + MinIO (wartet bis healthy)
pnpm docker:up:auth     # Mana Postgres (wartet bis healthy)
pnpm db:push            # Cards Drizzle-Schema
pnpm db:push:auth       # mana-auth Drizzle-Schema
pnpm dev                # cards api + web parallel (Turbo)
pnpm dev:auth           # mana-auth :3001

→ API auf http://localhost:3081, Web auf http://localhost:3082 (oder Vite-Dev-Default 5173).

Voraussetzung: Mana-Plattform-Stack (mana-auth, evtl. Föderations-Services) muss lokal laufen, sonst greift Auth-Login nicht.

Lizenz

Mana-Verein-intern, MIT (siehe mana/docs/COMPLIANCE.md für Details zur Verein-Lizenzpolitik).