J3vbandClaude Opus 5
9a0ae0dd2a
The separate J3vb/OwnCord-releases repo existed only because this repo was private: it carried the AGPL source snapshot and provided a publicly-readable update feed. Once this repo is public both roles collapse into its own Releases page, so the mirror is pure redundancy. - Server/config/config.go: github.repo default OwnCord-releases -> OwnCord. This one default drives both the server self-update and the client auto-update chain (tauri.conf.json updater.endpoints is empty, so the client resolves through the server). No test pinned the old value. - release.yml: drop the mirror step and its RELEASES_REPO_TOKEN guard, whose AGPL/private-repo premise no longer holds. The existing Create GitHub Release step is now the sole publish target. All 31 SHA pins verified intact. - Repoint the README badge/download link, both SECURITY.md links, the server-configuration table and sample, the system-overview diagram node and the CHANGELOG note. SECURITY.md's advisory link is the load-bearing one: left alone it would 404 once the mirror repo is deleted. - README: Go 1.25+ -> 1.26+ (badge and prerequisite) to match the toolchain actually required. Deleting the mirror repo loses nothing: both repos' v1.1.0-alpha.2 carry byte-identical asset sets, signatures and update manifest included. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OwnCord Architecture Blueprints
Verified against: commit ddc49f0, 2026-07-19
Companion audit: docs/audit-2026-07-19.md
This directory is the curated architectural map of OwnCord — the "blueprints" for the whole system. Every diagram is a Mermaid fenced block (GitHub renders these natively) followed by a prose explanation and a Source of truth file list.
Index
| Doc | Diagrams | Covers |
|---|---|---|
| system-overview.md | D1 System context, D8 Deployment topology | All processes, trust boundaries, ports, single-instance constraints |
| server.md | D2 Server package map, D3 REST request lifecycle | Go package structure, DB-access styles, middleware chain |
| websocket.md | D4 WS connect / replay / dispatch | Real-time engine: auth handshake, 3-tier reconnect replay, backpressure, typed dispatch |
| data-model.md | D5 Entity-relationship overview | All 23 tables from migrations 001–015, grouped by domain |
| voice-e2ee.md | D6 Voice + E2EE flow | LiveKit token flow, loopback TLS tunnel, ECDH key-holder relay |
| client.md | D7 Client module map | Tauri client: bootstrap, dispatcher, stores, Rust sidecars (structure, as-built) |
| ux/ | UX flow + state diagrams | Client behavior spec (target state): what every view does and how it reacts to events, permissions, and failure |
Structure vs. behavior
client.md maps the client as-built (modules, stores, wiring). The ux/ set is the complementary behavior spec — prescriptive (to-be) flows for every view, with per-view state matrices and event→reaction maps. Where today's code diverges from the target, the UX docs carry dated ⚠ Current gap callouts, so the set doubles as a UX improvement backlog.
Maintenance rule
These documents are curated, not generated. The rule that keeps them honest:
If a PR changes the structure of anything listed in a diagram's Source of truth list (new package, new table, new message type, changed flow), that PR updates the corresponding diagram in the same change.
Diagrams reference stable identifiers (package names, table names, message-type strings) rather than line numbers wherever possible. Line-number evidence lives in the dated audit reports, which are point-in-time snapshots by design.
Relationship to other docs
docs/api.md,docs/protocol.md,docs/schema.mdare the reference specs (request/response shapes, wire formats, DDL). These blueprints describe structure and flow, not payload shapes. Known drift between the specs and the code is catalogued in audit-2026-07-19.md §2.docs/client-architecture.mdpredates the abandonment of the Solid.js migration; client.md reflects the current state.