mirror of
https://github.com/LorenEteval/Furious.git
synced 2026-09-22 23:08:08 +03:00
3.8 KiB
3.8 KiB
Repository guidance
Inherit Furious/AGENTS.md and its root ancestor. Consult the Interface and Models guides when changing their
contracts. This scope owns restoration, migration, ordering, and persistence; workflows and presentation remain
outside it.
- Repositories restore, migrate, order, and persist profiles, subscriptions, routings, and TUN settings. They do not own network workflows, controller state, test schedulers, or presentation.
Storageowns one application-lifetime backend per collection and exposes live mutable collections for compatibility. Do not add a second cache/snapshot authority. Prefer named repository mutations so validation and commit boundaries can move behind the repository over time.- Preserve stable profile/subscription IDs, subscription ownership/key, ordering, unknown fields, and legacy schemas.
Active row/index and display text are compatibility/presentation state, not identity. Record-shape dispatch and
metadata precedence are migration behavior: legacy
UserServeraliases override nested metadata, and explicit top-level current fields then override those aliases. Preserve this order and unknown extras unless a tested migration deliberately changes it; do not treat every duplicate key as interchangeable. - A restore failure remains observable. Automatic cleanup must not replace unreadable persisted bytes with an empty fallback; only an explicit successful replacement may do so. Root decoding, individual-record hydration, and later serialization are separate failure boundaries. Test malformed records inside a valid root as well as malformed roots. Profile and subscription hydration publishes only a complete collection; an invalid record must not expose a partially restored prefix that cleanup can serialize over the original document.
- Stage fallible decode/migration before live mutation. Subscription reconciliation currently belongs to
Furious/Service/SubscriptionSync.pyand commits through the compatibility live collection: matched managed profiles retain object/profile identity and local metadata, removed profiles become stale, and unrelated groups remain intact. Do not add a second reconciliation algorithm here merely because persistence belongs to this scope. - Distinguish a live-collection commit from serialization/flush and subsequent controller effects. The compatibility collection can change before it is flushed; a successful in-memory synchronization is not proof of an atomic disk transaction. Preserve explicit flush/cleanup behavior and report failures at the boundary that actually failed. Batched UI commands may commit several live mutations; cancellation prevents later batches without restoring already committed ones. Do not impose whole-command atomicity without changing callers and failure semantics.
- Moving a profile to another subscription makes it a local member and clears its remote matching key; unchanged membership does not demote an already-managed profile. Removing a group definition alone does not delete profiles, cancel requests, or stop timers. Callers coordinate those effects through existing workflow boundaries; do not hide cascades inside a low-level repository operation.
- Verify legacy/current/unknown-field round trips, malformed roots, restore-failure preservation, ordering/stable
identity, group isolation, reconciliation commit behavior, and persistence in temporary QSettings namespaces. Use
tests/test_repository_contracts.pyandtests/test_subscription_sync.pyto revalidate this scope. Reordering a filtered view must preserve hidden slots, selected relative order, and unrelated profiles, then relocate activation by profile ID. Test the complete repository order as well as the visible projection; a correctly painted view can conceal a wrong persisted ordering.