Dashboard Magic OS

Dashboard Magic OS is a bilingual Obsidian workspace OS for collecting, organizing, applying, archiving, and presenting knowledge and life records.

Status: desktop alpha for controlled GitHub and BRAT testing. Organizer, Learning Threads, People & Health, and personalization transfer are usable; AI Steward remains visible but locked.

Languages

• English (en)
• Simplified Chinese (zh-CN)

简体中文说明

The project uses one codebase and two locale packs. Internal record fields and stable entity IDs remain language-neutral.

New vaults use a language-neutral MagicOS/ storage layout. Existing Dashboard OS vaults can keep their current Dashboard/ structure through a compatibility profile; setup never moves or renames existing files.

Development

npm install
npm run check
npm run build

Disclosures

• The public alpha has no telemetry, advertising, user account, or active AI network request.
• AI Steward is a planned paid feature. Its entrance remains visible, but every action is disabled until a separately delivered, verified entitlement and private runtime are connected.
• Future AI use will require the user's own supported Provider account and API credential in Obsidian SecretStorage. No Provider credential is bundled or exported.
• The public repository is MIT licensed. Private entitlement services, paid adapters, and operational infrastructure are separate works and are not included here.

See Privacy, Security, and Install, Upgrade, and Uninstall.

npm run check also enforces the privacy boundary: local settings are allowlisted, public upgrade registries may contain structural metadata only, unreviewed binary assets are rejected, and release artifacts are scanned for private paths and obvious secrets.

Repository boundary

This repository contains plugin source, tests, documentation, and distributable assets only. It must never contain a personal Obsidian vault, data.json, health records, person cards, API credentials, usage ledgers, snapshots, or backups.

See Data Boundary, Repository Boundary, i18n Migration, Runtime Migration Plan, Release Checklist, and Release Process.

Core-service acceptance evidence is recorded in P3 Core Services Acceptance.

The paid AI Steward migration is gated by the credential-free, fail-closed boundary in AI Steward Safety Audit. Entitlement verification and provider secrets remain private adapters and are never release data.

AI-authored record changes now have disconnected, test-only confirmation, durable crash journaling, atomic Obsidian persistence, and a recovery interface that remains available while AI is locked. See P4 AI Change Confirmation and Rollback Acceptance and P0 AI Change Journal Acceptance. Real-provider writes remain locked until this reviewed boundary is bundled into the installed private runtime.

The real Provider execution boundary is assembled in a still-disconnected sandbox with fixed endpoints, SecretStorage scope, bounded input/output, cancellation, accounting, and privacy-safe job projection. See P4 AI Provider Sandbox Acceptance.

The settings page can export and import a versioned, privacy-allowlisted personalization package without carrying vault bindings or runtime data. See P5 Personalization Acceptance.

The first P4 application slice, a read-only Organizer built on stable asset relations, is documented in P4 Organizer Acceptance.

The private production OS and public core remain isolated during migration. Their ownership and controlled backport direction are tracked in the Public / Private Sync Matrix.

The second P4 application slice, read-only Learning Threads, is documented in P4 Learning Threads Acceptance.

The third P4 application slice, privacy-projected People & Health, is documented in P4 People & Health Acceptance.

The fourth P4 application slice keeps the paid AI Steward entrance visible while all model actions remain disabled behind the audited private-runtime boundary. See P4 AI Steward Shell Acceptance.

The credential-free AI lifecycle is verified with a deterministic, non-networked simulation in P4 AI Simulation Pipeline Acceptance.

The five cabins now share a unified object inspector, unprofiled-object queue, transition guard, reversible operation plan, and workspace checkpoint boundary. See P7 Unified Object Workbench Acceptance.

The next migration is governed by a replacement-first audit: new shared capabilities must retire duplicated catalogs, classifiers, write paths, and workflow shells instead of accumulating beside them. See P8 Lean Replacement Audit.

License

Public repository source is available under the MIT License. Private paid-service components are not included in this repository.