v2/v3: community module integration — session pinning + annotation persistence #25

New issue

Open

opened 2026-04-12 18:37:44 -07:00 by pyr0ball · 0 comments

pyr0ball commented

2026-04-12 18:37:44 -07:00

Owner

Summary

Once circuitforge-core ships the community module (currently on hold pending Kiwi/Peregrine/Snipe integration tests), Linnet should wire it in for server-side annotation persistence.

What to use from `cf-core community`

CommunityDB — PostgreSQL pool + migration runner. Generic enough to use directly for any Linnet server-side persistence (session snapshots, correction events).
SharedStore base class — subclass as LinnetAnnotationStore(SharedStore) in app/services/annotation_store.py for typed reads/writes.
source_product column — schema is already multi-product aware; Linnet sets source_product="linnet".

What NOT to use

CommunityPost — Kiwi-specific food schema. Linnet defines its own ToneAnnotationRecord dataclass.
Community migrations — Linnet adds its own community_tone_annotations migration.

Integration points by milestone

Milestone	Use case	Implementation
v0.2.x	Session export	`LinnetAnnotationStore.insert_annotation_session()` — writes pinned exports to PostgreSQL
v1.0	Session pinning (Paid+)	Session snapshots written on pin; slug returned as resume deep link
Post-v1.0	Correction training corpus	Each labeling action → `insert_correction_event()` → feeds media library training pipeline
Post-v1.0	Community label sharing	Optional opt-in: anonymized tone correction events shared across menagerie

Blockers

cf-core community module must ship first (on hold — see community module PR)
Session pinning design must be finalised (v1.0 open question)

Labels

enhancement cf-core-dep backlog

## Summary Once `circuitforge-core` ships the `community` module (currently on hold pending Kiwi/Peregrine/Snipe integration tests), Linnet should wire it in for server-side annotation persistence. ## What to use from `cf-core community` - **`CommunityDB`** — PostgreSQL pool + migration runner. Generic enough to use directly for any Linnet server-side persistence (session snapshots, correction events). - **`SharedStore` base class** — subclass as `LinnetAnnotationStore(SharedStore)` in `app/services/annotation_store.py` for typed reads/writes. - **`source_product` column** — schema is already multi-product aware; Linnet sets `source_product="linnet"`. ## What NOT to use - `CommunityPost` — Kiwi-specific food schema. Linnet defines its own `ToneAnnotationRecord` dataclass. - Community migrations — Linnet adds its own `community_tone_annotations` migration. ## Integration points by milestone | Milestone | Use case | Implementation | |---|---|---| | v0.2.x | Session export | `LinnetAnnotationStore.insert_annotation_session()` — writes pinned exports to PostgreSQL | | v1.0 | Session pinning (Paid+) | Session snapshots written on pin; slug returned as resume deep link | | Post-v1.0 | Correction training corpus | Each labeling action → `insert_correction_event()` → feeds media library training pipeline | | Post-v1.0 | Community label sharing | Optional opt-in: anonymized tone correction events shared across menagerie | ## Blockers - `cf-core` community module must ship first (on hold — see community module PR) - Session pinning design must be finalised (v1.0 open question) ## Labels `enhancement` `cf-core-dep` `backlog`