Sync latest TrueGrowth updates

openspec/changes/add-desktop-auto-updates/design.md

@@ -0,0 +1,15 @@
+## Context
+The desktop app is packaged with Electron and electron-builder. Updates will be served from a static 1Panel/Nginx site instead of a business backend.
+
+## Decisions
+- Use `electron-updater` with electron-builder `generic` publishing.
+- Reserve `https://truegrowth.benchu.cloud/desktop/stable/` as the stable update channel root.
+- Keep mac `dmg` for first install and mac `zip` for auto updates.
+- Keep Windows `nsis` as the installed auto-update target and `portable` as a manual-download artifact only.
+- Do not automatically restart the app after download; users confirm restart from the renderer UI.
+- Desktop update UI supersedes the existing web Service Worker update prompt inside Electron so customers do not see two update concepts at once.
+
+## Release Notes
+- macOS customer auto updates require Developer ID signing and notarization before production distribution.
+- Windows production releases should be Authenticode signed to reduce SmartScreen and security-product friction.
+- Unsigned builds may be used for local or internal update-flow tests only.

openspec/changes/add-desktop-auto-updates/proposal.md

@@ -0,0 +1,15 @@
+# Change: Add desktop auto updates
+
+## Why
+TrueGrowth desktop customers need a reliable way to receive macOS and Windows client updates after installation without a custom backend.
+
+## What Changes
+- Add Electron auto update support backed by the 1Panel static origin at `https://truegrowth.benchu.cloud/desktop/stable/`.
+- Expose update status and commands to the renderer through the desktop preload bridge.
+- Add a branded lower-left update entry and dialog for checking, downloading, progress, retry, and restart-to-install.
+- Add release manifest tooling for `latest.yml`, `latest-mac.yml`, and `releases.json`.
+- Treat production signing as a release gate for customer auto-update packages.
+
+## Impact
+- Affected specs: desktop-auto-updates
+- Affected code: Electron main/preload, electron-builder config, Workbench shell UI, release scripts

openspec/changes/add-desktop-auto-updates/specs/desktop-auto-updates/spec.md

@@ -0,0 +1,34 @@
+## ADDED Requirements
+
+### Requirement: Desktop Auto Update Channel
+The desktop application SHALL use `https://truegrowth.benchu.cloud/desktop/stable/` as the default stable auto-update channel.
+
+#### Scenario: Packaged client checks for updates
+- **GIVEN** a packaged installed desktop client
+- **WHEN** the scheduled or manual update check runs
+- **THEN** the client SHALL query the generic update metadata from the stable channel.
+
+### Requirement: Desktop Update UI
+The desktop application SHALL expose update status in the lower-left navigation utility area and provide a branded dialog for update actions.
+
+#### Scenario: Update is available
+- **WHEN** the updater reports a new version
+- **THEN** the UI SHALL show the version, release notes when available, and a download action.
+
+#### Scenario: Update is downloaded
+- **WHEN** the updater finishes downloading an update
+- **THEN** the UI SHALL offer restart-to-install without forcing restart automatically.
+
+### Requirement: Release Artifact Manifest
+The release tooling SHALL produce a `releases.json` manifest alongside electron-builder update metadata for the 1Panel static directory.
+
+#### Scenario: Release artifacts are prepared
+- **WHEN** desktop release artifacts exist in the release output directory
+- **THEN** the tooling SHALL record version, channel URL, files, sizes, sha256 hashes, and upload guidance.
+
+### Requirement: Production Signing Gate
+Production auto-update releases SHALL require platform signing before customer distribution.
+
+#### Scenario: Unsigned production package
+- **WHEN** a production customer release is prepared without required platform signing
+- **THEN** the release SHALL be treated as not ready for customer auto-update distribution.

openspec/changes/add-desktop-auto-updates/tasks.md

@@ -0,0 +1,13 @@
+## 1. Implementation
+- [x] 1.1 Add `electron-updater` dependency.
+- [x] 1.2 Configure electron-builder generic publishing at the TrueGrowth stable update URL.
+- [x] 1.3 Implement Electron update state, events, manual checks, download, and restart-install commands.
+- [x] 1.4 Expose a safe preload update bridge to the renderer.
+- [x] 1.5 Add Workbench update entry and dialog with light/dark styling.
+- [x] 1.6 Add release manifest generation/verification tooling for 1Panel upload.
+
+## 2. Validation
+- [x] 2.1 Run Electron main/preload syntax checks.
+- [x] 2.2 Run web typecheck for the Workbench UI.
+- [x] 2.3 Run the release manifest script with a fixture release directory.
+- [ ] 2.4 Validate OpenSpec change if the `openspec` CLI is available. (`openspec` was not found in PATH.)

openspec/changes/replace-funclip-with-videoagent-clip-workbench/design.md

@@ -0,0 +1,40 @@
+## Context
+VideoAgent is a broad Python agent framework for video understanding, editing, audio processing, and creative remaking. It is not a stable desktop SDK, so TrueGrowth must wrap it behind a local JSON task adapter and keep heavy dependencies isolated from Electron and the web renderer.
+
+## Goals / Non-Goals
+- Goals: make VideoAgent the clip workbench primary runtime, provide a customer-facing intent-first editing flow, and write structured deliverables back to tasks/assets.
+- Goals: support a useful MVP even when the full VideoAgent model stack is not installed.
+- Non-Goals: bundle full Python, CUDA, PyTorch, ONNX, or model packages into the default desktop/web process.
+- Non-Goals: expose VideoAgent, FunClip, CUDA, model paths, or command-line details in customer-facing UI.
+
+## Decisions
+- Decision: run VideoAgent as an independent `videoagent-local` sidecar managed by the existing local API process.
+- Decision: use a stable TrueGrowth JSON task shape instead of directly driving VideoAgent's interactive CLI.
+- Decision: treat capability groups as installable/readiness-gated packages: basic clipping, video understanding, creative remaking, and voice/audio processing.
+- Decision: the first implementation must provide a deterministic MVP plan/result fallback so the clip center can complete a real task loop before the full third-party runtime is installed.
+- Decision: source inputs are workflow-aware. Understanding, transcription, text editing, and most long-to-short jobs use one primary video/audio source; B-roll, platform packaging, and remaking jobs use a primary source plus references; montage, batch processing, and script-to-video jobs may use multiple videos, images, and audio assets.
+- Decision: structured plans, transcripts, SRT, timeline, titles, cover prompts, and publish copy are task deliverables first. They are written to task metadata and only become asset-center media records when a real playable media file or publishable image exists.
+- Decision: first-screen quick scenarios show only workflows that can close with the current adapter and model-center capabilities: transcription/subtitles, long-to-short planning, transcript editing, video summary/Q&A, course/interview/ecommerce/podcast planning, B-roll planning, multi-source montage planning, and script-to-video planning.
+- Decision: VideoAgent demo features that require heavy optional stacks, such as ImageBind semantic retrieval, Seed-VC voice conversion, DiffSinger singing/music-video, or specialized voice-remake models, remain hidden from first-screen quick scenarios until the model center reports the required pack as initialized.
+- Decision: model requirements are mapped to TrueGrowth capability packs instead of raw third-party names. Whisper/FunASR map to `字幕转写`, CosyVoice/FishSpeech/IndexTTS-style models map to `配音音色`, LatentSync/MuseTalk/Wav2Lip-style models map to `数字人口播`, ImageBind maps to `素材语义检索`, Seed-VC maps to `声音重制`, and DiffSinger maps to `音乐视频`.
+- Decision: customer first use bundles only the lightweight adapter, media handling, and checks that are safe for the desktop package. Larger Mac/Windows model packs are initialized through the existing model center so storage, platform, license, and GPU constraints can be shown in one place.
+
+## API Contract
+- `GET /local-api/videoagent` returns readiness, visible capability groups, service status, and setup progress.
+- `POST /local-api/runtime/videoagent/start` starts or prepares the sidecar and returns an async startup state.
+- `POST /local-api/runtime/videoagent/stop` stops the sidecar if it is running.
+- `POST /local-api/videoagent/tasks` accepts source, goal, scene, platform, output options, model routing, and package flags.
+- `POST /local-api/videoagent/tasks` also accepts `sources`, `primarySourceId`, `sourceMode`, `acceptedSourceTypes`, and `supportingSourceIds` for workflows that need multiple materials.
+- `GET /local-api/videoagent/tasks/:id` returns task status, progress, generated plan, transcript, segments, deliverables, and asset ids.
+
+## Risks / Trade-offs
+- VideoAgent dependencies are heavy and platform-sensitive. Mitigation: isolate runtime, detect capability groups independently, and keep a deterministic MVP fallback.
+- VideoAgent is research-oriented. Mitigation: wrap it behind TrueGrowth task adapters and avoid exposing internal graph prompts or CLI details.
+- Existing FunClip tasks may exist in history. Mitigation: keep history display able to read legacy `funclip-local` records while new submissions use `videoagent-local`.
+
+## Migration Plan
+1. Add VideoAgent local runtime status and task endpoints.
+2. Switch the clip workbench submission path to `videoagent-local`.
+3. Replace capability-card-first UI with source/goal/plan/result workflow.
+4. Preserve existing assets, task history, and publish handoff behavior.
+5. Remove visible FunClip copy and provider jargon from the page.

openspec/changes/replace-funclip-with-videoagent-clip-workbench/proposal.md

@@ -0,0 +1,16 @@
+# Change: Replace FunClip clip center with VideoAgent workbench
+
+## Why
+The current FunClip-based clip center has not completed a reliable editing loop, and its clipping model is too narrow for a commercial AI video production workflow. TrueGrowth needs the clip center to start from user intent and source media, then produce plans, transcripts, segments, packaged outputs, and publishing assets through a broader VideoAgent-style runtime.
+
+## What Changes
+- **BREAKING**: Move the customer-facing AI clip workbench primary provider from `funclip-local` to `videoagent-local`.
+- Add a local VideoAgent sidecar contract with readiness, start/stop, task submission, polling, and asset-writing endpoints.
+- Replace the fixed capability-card-first flow with an intent-first workflow: source media, natural-language goal, business scene, output package, generated plan, execution, and deliverables.
+- Expose customer-facing capability groups for basic clipping, video understanding, creative remaking, and voice/audio processing without showing third-party runtime names.
+- Keep FunClip only as a hidden migration fallback where needed; it must not define visible product capability or user copy.
+
+## Impact
+- Affected specs: `ai-clip-workbench`
+- Affected code: `scripts/truegrowth-local-api.mjs`, `apps/web/src/workbench/WorkbenchShell.tsx`, `apps/web/src/workbench/workbench.scss`
+- Runtime integration: new `/local-api/videoagent*` local API family, replacing visible `/local-api/funclip/tasks` usage in the clip workbench

openspec/changes/replace-funclip-with-videoagent-clip-workbench/specs/ai-clip-workbench/spec.md

@@ -0,0 +1,101 @@
+## ADDED Requirements
+### Requirement: VideoAgent Primary Runtime
+The AI clip workbench SHALL submit new customer-facing clip tasks to `videoagent-local` instead of `funclip-local`.
+
+#### Scenario: User submits a new clip job
+- **WHEN** the user submits a configured AI clip job
+- **THEN** the created task uses provider id `videoagent-local`
+- **AND** customer-facing UI does not mention FunClip, VideoAgent, CUDA, model paths, or command-line details
+
+### Requirement: Intent-First Clip Workflow
+The AI clip workbench SHALL begin with source media and a natural-language production goal rather than a fixed list of clip presets.
+
+#### Scenario: User defines the desired output
+- **WHEN** the user selects source media and enters a goal such as turning a long course into short clips
+- **THEN** the page captures the source, goal, business scene, platform format, and desired output package before task submission
+
+### Requirement: Simplified First-Screen Monitor
+The AI clip workbench SHALL present the first screen as a prompt-led work area with a single video monitor on the right.
+
+#### Scenario: User has not selected media
+- **WHEN** the user opens the first screen without selected media
+- **THEN** the right-side monitor shows only two primary source actions: choose from the asset center or upload a local file
+- **AND** the visible flow does not show the legacy capability-template wall
+
+#### Scenario: User selects media
+- **WHEN** the user chooses a video source
+- **THEN** the right-side monitor previews the selected video and keeps source replacement inside the monitor controls
+
+### Requirement: Workflow-Aware Multi-Source Inputs
+The AI clip workbench SHALL choose the source input model from the selected workflow rather than assuming every job is a single-video trim.
+
+#### Scenario: User chooses a single-primary workflow
+- **WHEN** the user selects workflows such as transcript editing, auto captions, summary Q&A, course chapters, interview Q&A, or talking-head cleanup
+- **THEN** the page requires one primary video or audio source
+- **AND** optional reference media stays secondary and does not replace the primary monitor preview
+
+#### Scenario: User chooses a multi-source workflow
+- **WHEN** the user selects workflows such as multi-source montage, script-to-video, B-roll planning, platform packaging, or batch processing
+- **THEN** the page allows multiple image, video, and audio assets from the asset center or local upload according to that workflow
+- **AND** the submitted payload identifies primary source, supporting sources, source mode, accepted media types, and cardinality
+
+### Requirement: Shared Asset Center Picker
+The AI clip workbench SHALL reuse the shared asset center picker for source selection.
+
+#### Scenario: User chooses from asset center
+- **WHEN** the user clicks the source monitor asset-center action
+- **THEN** the shared asset center modal opens with existing media browsing, preview, upload, delete, and multi-select behavior
+- **AND** generated works from other TrueGrowth modules are available as selectable assets when they have a valid media URL
+
+### Requirement: Quick Scenarios Configure The Job
+The AI clip workbench SHALL expose practical quick scenarios based on supported clip-workbench abilities and mainstream AI editing workflows.
+
+#### Scenario: User clicks a quick scenario
+- **WHEN** the user selects a quick scenario such as long-video highlights, transcript editing, course chapters, interview Q&A, ecommerce live clips, auto captions, publish packaging, source montage, or script-to-video planning
+- **THEN** the page fills the production goal and updates clip count, duration, platform, subtitle, speaker, context, title, publishing, batch, and regrouping options where applicable
+
+#### Scenario: Capability is not first-version ready
+- **WHEN** a VideoAgent demo ability depends on advanced voice conversion, singing, music-video generation, or semantic retrieval models that are not connected through the current TrueGrowth model center
+- **THEN** the ability is not shown as a first-screen quick scenario
+- **AND** the service check or model center may show it as an optional future capability without blocking the basic clip workflow
+
+### Requirement: Structured Clip Plan And Deliverables
+The AI clip workbench SHALL display a structured AI plan and generated deliverables for each submitted task.
+
+#### Scenario: Task returns a plan
+- **WHEN** a clip task is running or complete
+- **THEN** the page shows the planned steps, transcript or draft transcript, candidate segments with reasons, timeline items, and deliverables such as SRT, title, cover prompt, publish copy, and video assets when available
+
+#### Scenario: Adapter returns only structured deliverables
+- **WHEN** the local adapter can generate a plan, transcript, segments, timeline, and publishing deliverables but has not rendered a playable video file
+- **THEN** the task completes with structured result metadata and no generated video asset id
+- **AND** the asset center does not receive an unplayable placeholder video or JSON plan asset
+- **AND** the UI offers result editing from the structured task result without implying a playable video exists
+
+### Requirement: Capability Package Readiness
+The local runtime SHALL report customer-facing readiness for basic clipping, video understanding, creative remaking, and voice/audio processing packages.
+
+#### Scenario: User opens service check
+- **WHEN** the user opens the clip workbench service check dialog
+- **THEN** the page shows package readiness as available, preparing, or needs initialization without exposing third-party technical names
+
+### Requirement: Model Center Reuse
+The AI clip runtime SHALL reuse existing TrueGrowth model-center and digital-human capabilities before requesting VideoAgent-specific model downloads.
+
+#### Scenario: Existing local models can satisfy a clip capability
+- **WHEN** the model center already has usable ASR, voice, image/video, or digital-human models
+- **THEN** clip readiness counts those models as reusable for transcription, voice, B-roll planning, or digital-human handoff
+- **AND** the customer does not need to download duplicate Whisper, CosyVoice, fish-speech, or digital-human model packages for the same first-version function
+
+#### Scenario: Optional advanced model is missing
+- **WHEN** ImageBind, Seed-VC, DiffSinger, or similar advanced packages are not present
+- **THEN** first-version quick scenarios remain available for plan, transcript, segment, montage, and publish deliverables
+- **AND** advanced semantic search, voice conversion, or music-video workflows are presented only as optional initialization from the model center
+
+### Requirement: Legacy FunClip Migration Fallback
+The system SHALL preserve existing FunClip task history while preventing FunClip from defining the new customer-facing clip workflow.
+
+#### Scenario: User has older clip tasks
+- **WHEN** the task history contains older `funclip-local` records
+- **THEN** the history can still display them as clip workbench tasks
+- **AND** new submissions use `videoagent-local`

openspec/changes/replace-funclip-with-videoagent-clip-workbench/tasks.md

@@ -0,0 +1,31 @@
+## 1. Specification
+- [x] 1.1 Add proposal, design notes, and spec deltas for the VideoAgent clip workbench migration.
+
+## 2. Local Runtime
+- [x] 2.1 Add `videoagent-local` readiness, package status, and start/stop runtime management to the local API.
+- [x] 2.2 Add `/local-api/videoagent/tasks` task creation, polling, and structured result payloads.
+- [x] 2.3 Write VideoAgent task deliverables back to the unified task stream and generated asset list.
+
+## 3. Workbench UI
+- [x] 3.1 Refactor the clip page from FunClip-first naming/copy to AI clip workbench / VideoAgent-backed behavior.
+- [x] 3.2 Replace the fixed 12-card first step with source + natural-language goal + scene/output package configuration.
+- [x] 3.3 Add generated plan, transcript, candidate segments, deliverables, and result preview surfaces.
+- [x] 3.4 Keep service status and task history in dialogs with customer-facing copy only.
+- [x] 3.5 Simplify the first screen into a prompt-led left panel and a right-side video monitor with only asset-center and local-upload entry points before media is selected.
+- [x] 3.6 Replace visible legacy template selection with quick scenarios that fill the prompt and configure output options.
+- [x] 3.7 Reuse the shared asset center modal for clip source selection, including multi-select where the workflow supports it.
+- [x] 3.8 Add workflow-aware source modes for single primary video/audio, primary plus reference media, multi-source montage, script-to-video, and batch processing.
+- [x] 3.9 Align first-screen form controls and source tray with the `/image` golden page form standard.
+- [x] 3.10 Hide unsupported advanced demo abilities from the first-screen quick scenarios and show only current MVP workflows.
+- [x] 3.11 Replace broad legacy output toggles with scenario-specific output options.
+
+## 4. Runtime And Assets
+- [x] 4.1 Stop creating asset-center output assets when the adapter only returns structured plans or JSON files.
+- [x] 4.2 Allow runtime-generated assets to be deleted from the local API and asset center.
+- [x] 4.3 Map VideoAgent model needs to reusable TrueGrowth model-center capability packs and optional advanced packs.
+
+## 5. Verification
+- [ ] 5.1 Validate the OpenSpec change. (`openspec` / `pnpm exec openspec` not available in this environment.)
+- [x] 5.2 Run focused TypeScript or app checks.
+- [x] 5.3 Run a local API smoke check for status and task creation.
+- [x] 5.4 Browser-check the simplified `/timeline` first screen, source picker, upload affordance, quick scenario behavior, and dark/light styling.

openspec/changes/unify-local-data-persistence/design.md

@@ -0,0 +1,25 @@
+## Context
+The desktop shell already pins Electron `userData`, but development Local API runs can still default to `.truegrowth-runtime`, while packaged or Electron-launched runs use `Application Support/TrueGrowth/runtime`. Browser `localStorage` and `IndexedDB` are origin scoped, so `127.0.0.1:7200` and preview ports cannot share data directly.
+
+## Goals / Non-Goals
+- Goals: make desktop business data survive restarts and port changes, expose storage health, migrate legacy runtime records, and avoid duplicating large media files.
+- Non-Goals: rewrite every browser IndexedDB cache in one step, delete legacy runtime folders, or bundle a new native database dependency.
+
+## Decisions
+- Use `~/Library/Application Support/TrueGrowth/data/truegrowth.sqlite` (platform equivalent on Windows/Linux) as the canonical ledger.
+- Continue using the existing `sqlite3` CLI integration pattern to avoid adding native npm dependencies.
+- Store structured business records as JSON payloads in typed ledger tables, with a `kv` table for aggregate state and migration markers.
+- Keep JSON shadows during migration for compatibility, but prefer SQLite reads whenever available.
+- Index legacy large files by absolute path and local media URL; do not copy the 35GB `.truegrowth-runtime` tree by default.
+
+## Risks / Trade-offs
+- SQLite CLI may be missing on a fresh machine. Mitigation: diagnostics report unavailable status and Local API falls back to existing JSON behavior until the runtime readiness flow installs or bundles SQLite.
+- Browser-only IndexedDB data cannot be read by Node without Chromium internals. Mitigation: make the desktop Local API the authoritative source going forward and keep browser storage as a transitional source.
+- Migration may discover stale or deleted files. Mitigation: diagnostics report missing targets and preserve legacy source metadata.
+
+## Migration Plan
+1. Create canonical data/runtime directories under desktop user data.
+2. Initialize ledger schema and record current storage roots.
+3. Import legacy runtime tasks, cleared task IDs, business workflow JSON/SQLite state, AIGCPanel state, social publishing state, and media file indexes.
+4. Keep legacy files untouched and record migration versions in `storage_migrations`.
+5. Expose diagnostics so support can see which roots are active and which legacy sources were imported.

openspec/changes/unify-local-data-persistence/proposal.md

@@ -0,0 +1,15 @@
+# Change: Unify TrueGrowth local data persistence
+
+## Why
+TrueGrowth desktop currently stores business data across Electron browser storage, project-local runtime files, desktop runtime files, JSON shadows, and small SQLite stores. Repeated local runs and different ports can make data appear lost because each browser origin and runtime root sees a different persistence estate.
+
+## What Changes
+- Add one desktop-local persistence contract centered on a canonical per-user data directory and SQLite ledger.
+- Route Local API business data through the canonical storage layer for tasks, assets, workflow state, social publishing state, runtime settings, and migration records.
+- Add diagnostics, migration, export, and import endpoints so data roots and legacy sources are visible and recoverable.
+- Keep browser storage for UI preferences, caches, and temporary offline queues rather than treating it as the final business-data source.
+- Preserve legacy project-local runtime data by indexing or importing metadata without deleting or moving large output files automatically.
+
+## Impact
+- Affected specs: `desktop-local-persistence`
+- Affected code: `scripts/truegrowth-local-api.mjs`, Electron startup environment, local runtime client helpers, storage diagnostics and migration flows

openspec/changes/unify-local-data-persistence/specs/desktop-local-persistence/spec.md

@@ -0,0 +1,49 @@
+## ADDED Requirements
+
+### Requirement: Canonical Desktop Data Root
+TrueGrowth SHALL use a single writable per-user desktop data root as the canonical location for business persistence.
+
+#### Scenario: Local API starts outside Electron
+- **WHEN** the Local API starts without explicit runtime path environment variables
+- **THEN** it resolves the same platform user data root that Electron uses
+- **AND** it stores canonical data under a `data` directory and runtime outputs under a `runtime` directory.
+
+#### Scenario: Electron starts the Local API
+- **WHEN** Electron launches or imports the Local API
+- **THEN** it provides the canonical `TRUEGROWTH_ELECTRON_USER_DATA` and `TRUEGROWTH_RUNTIME_STATE_DIR`
+- **AND** repeated desktop launches use the same persisted data root.
+
+### Requirement: SQLite Business Ledger
+TrueGrowth SHALL store desktop business records in a canonical SQLite ledger.
+
+#### Scenario: Runtime task is created
+- **WHEN** a local runtime task is queued, updated, completed, failed, or cleared
+- **THEN** the task and clear marker are written to the ledger
+- **AND** restarting the Local API restores the latest task state from the ledger.
+
+#### Scenario: Runtime asset is imported or generated
+- **WHEN** a media asset is imported or generated
+- **THEN** its metadata is written to the ledger with local file path and URL identity
+- **AND** the media file remains in the managed runtime output directory or its indexed legacy path.
+
+#### Scenario: Workflow or publishing state changes
+- **WHEN** workflows, schedules, runs, events, accounts, campaigns, or jobs change
+- **THEN** the aggregate state is saved to the ledger
+- **AND** JSON shadow files remain compatible during migration.
+
+### Requirement: Storage Diagnostics And Migration
+TrueGrowth SHALL expose local storage diagnostics and safe migration controls.
+
+#### Scenario: User checks storage health
+- **WHEN** a client requests storage diagnostics
+- **THEN** the response includes canonical paths, active runtime path, SQLite availability, ledger path, legacy source status, and warnings for split roots.
+
+#### Scenario: Legacy project runtime exists
+- **WHEN** migration runs and `.truegrowth-runtime` contains previous records or outputs
+- **THEN** TrueGrowth imports metadata and indexes file paths without deleting or copying large files by default
+- **AND** records the migration result in the ledger.
+
+#### Scenario: User exports or imports local data
+- **WHEN** export or import is requested
+- **THEN** TrueGrowth serializes or restores ledger-managed business data through the Local API
+- **AND** invalid import payloads are rejected without clearing existing data.

openspec/changes/unify-local-data-persistence/tasks.md

@@ -0,0 +1,26 @@
+# Tasks: Unified local persistence
+
+## 1. Specification
+- [x] 1.1 Create OpenSpec proposal, design, task list, and delta spec.
+- [ ] 1.2 Validate with `openspec validate unify-local-data-persistence --strict` once the OpenSpec CLI is available in this checkout.
+
+## 2. Local API Storage
+- [x] 2.1 Resolve canonical desktop data and runtime paths for Electron and standalone Local API runs.
+- [x] 2.2 Initialize `truegrowth.sqlite` with tables for tasks, assets, project records, settings, workflow state, social publishing, and migration records.
+- [x] 2.3 Persist runtime tasks, cleared task IDs, runtime assets, workflow state, social publishing state, AIGCPanel state, and runtime settings to the ledger.
+- [x] 2.4 Preserve JSON shadow files for compatibility while preferring ledger reads.
+- [x] 2.5 Persist Drawnix workspace folders, boards, and workspace state through the Local API ledger while keeping IndexedDB as a shadow/offline fallback.
+
+## 3. Migration And Diagnostics
+- [x] 3.1 Add storage diagnostics, migrate, export, and import endpoints.
+- [x] 3.2 Import legacy `.truegrowth-runtime` metadata without moving large files.
+- [x] 3.3 Report split roots, SQLite availability, and canonical path status.
+
+## 4. Client And Verification
+- [x] 4.1 Add frontend Local API client helpers and types for the storage endpoints.
+- [x] 4.2 Run Node syntax checks, TypeScript checks, and targeted Local API verifier coverage.
+- [x] 4.3 Document remaining browser IndexedDB transition limits.
+
+## Notes
+- OpenSpec strict validation is still pending because the local `openspec` CLI is not available in this checkout (`pnpm exec openspec ...` reports command not found).
+- Browser IndexedDB remains as an offline/shadow cache for Drawnix workspace and UI-only preferences; Local API/SQLite is now authoritative when the desktop Local API is reachable.