Cybercore master documentation

Public operator reference · Cybercore Systems Framework

This is the public-safe Cybercore documentation set. It is authored from Cybercore-owned public source and intentionally excludes internal notes, machine-specific paths, credentials, personal data, and internal operational records.

Public project surfaces

All mutating operations require explicit operator intent. Examples use generic local paths and must be adapted to the installation environment.

Architecture and product map

Cybercore uses a shared Rust framework for themes, components, effects, packs, quality checks, and updater operations. Products consume the shared contracts while keeping their own runtime and presentation layers.

Core surfaces

Surface	Responsibility
Core crates	Tokens, components, effects, packs, and validation
Theme Studio	Local theme authoring and preview
Updater engine	Discovery, planning, installation, repair, and rollback
Updater TUI	Keyboard-driven operator dashboard
Updater Panel	Loopback Control Panel for fleet operations
Public docs	Sanitized reference published from Cybercore-owned source

The updater manifest defines product consumers and shared synchronization tasks. The public task pages are generated from that manifest so names and coverage remain aligned.

Updater operations

The compatibility command is dry-run by default:

cybercore-update
cybercore-update --apply
cybercore-update --tui

The Rust surfaces provide planning, inspection, apply, repair, service restart, rollback, theme health, GitHub read-only status, repository diff review, and bounded operation history.

Safety rules

Dirty worktrees are blocked unless generated outputs are explicitly allowlisted.
Apply, repair, restart, and rollback require explicit confirmation.
Binary replacement creates a backup before installation.
User services use systemctl --user; system escalation is never silent.
The updater does not commit or push repository changes automatically.

Updater TUI

The TUI is a Ratatui dashboard for selecting fleet tasks and reviewing real operation state.

Key	Action
`I`	Inspect fleet diagnostics
`T`	Inspect theme health
`U`	Confirm theme synchronization
`G`	Read GitHub repository status
`D`	Review repository differences
`H`	View operation history
`P`	Preview a plan
`Enter`	Confirm and apply
`R`	Confirm repair/retry
`S`	Confirm service restart
`B`	Confirm rollback
`Y` / `N`	Confirm or cancel
`Q` / `Esc`	Quit or cancel

Cybercore status colors distinguish navigation, selection, ready, running, failure, and diagnostics states.

Updater Control Panel

The loopback Control Panel exposes the fleet dashboard and extended operations without replacing the CLI or TUI.

Supported operations

Fleet task discovery and diagnostics
Non-mutating plan generation
Apply, repair/retry, service restart, and rollback actions
Visible action results and duplicate-action protection
Theme and repository workspace status

The Panel is intended for local use. Keep it bound to loopback and place any remote access behind an authenticated, explicitly configured gateway.

Themes and assets

Cybercore’s target theme model contains 312 themes:

300 canonical source palettes
12 signature mashups

Theme synchronization derives from the canonical public registry, preserves family metadata, and tracks generated outputs so unrelated local themes are not removed.

Theme quality checks cover schema validity, rendering, contrast, appearance variants, and shared component compatibility. Theme Studio is the authoring surface; products consume the resulting public contracts.

Recovery and validation

Before release, validate the Rust workspace, compatibility dry-run, updater plan, live fleet diagnostics, services, and theme totals.

Recovery

The updater creates a sibling backup before replacing an installed binary. Rollback restores the most recent backup for a selected task. Repair retries a blocked or failed task after its diagnostic condition has been resolved.