The Spark DadaTracker

ADAPTER SDK ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: F.O.U.R. → Forgey Foundry
Logical role: Developer SDK, scaffolding, validation, and adapter contract toolkit
Canonical source candidate: D:\THE SPARK\FOUR\03_Forgey_Foundry\01_Engines\02_Adapter_SDK
Weight status: Proposed 5% of Forgey Foundry; provisional pending parent rebalancing.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Provide the supported safe developer kit for connecting applications, components, providers, evidence systems, and profiles to Foundry contracts without copying engine, router, updater, or control logic.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

Approved adapter categories can be created with stable APIs, deterministic scaffolds, validated manifests, least-privilege capabilities, tests, packages, migration guidance, diagnostics, documentation, and proven compatibility.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- v1 categories: component, watcher-profile, provider, evidence, and approved application-integration adapters.
- Start with Python; add TypeScript only when current components demonstrably require it.
- Generated adapters contain boundaries, manifests, lifecycle hooks, validation, tests, and examples—not business logic.
- Dependencies use allowlists, lockfiles, vulnerability review, reproducible installation, and minimal defaults.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

Generate and validate one component adapter and one profile adapter using fixtures and stable contracts.

Comfortably Functional / Purple:

A routine developer workflow provides docs, examples, migrations, diagnostics, approved languages, reliable packaging, and low-friction compatibility checks.

First Green work target / pause point:

Generate a fixture adapter that passes schema, permission, package, and end-to-end tests, then pause.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==============================================================================

01. Scope and adapter taxonomy                              10%   20–36h
02. Contracts and public API                                15%   40–75h
03. Scaffolding and templates                               18%   50–90h
04. Validators and diagnostics                              15%   40–75h
05. Capability and permission model                         12%   35–65h
06. Packaging and lifecycle metadata                        10%   30–60h
07. Integration proof                                       12%   45–80h
08. Hardening, documentation, and release         

F.O.U.R. — ARCHIVE AND CONTINUITY ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R.
Component type: Archive, migration-evidence, and continuity family
Proposed parent allocation: 2% proposed
Numerical Blue Current rule: Preserve the current numerical DadaTracker value as provisional and label the accepted method; never present tiered verification as Full SHA-256.
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the complete preservation and continuity system for legacy roots, migration evidence, snapshots, superseded material, restoration, and safe future cleanup.

Plain-language purpose:
The place keeping old systems and proof safe so nothing important is lost during change.

Explicitly not:
The active source tree, a substitute for disaster backup, or permission to delete legacy roots.

==============================================================================
100% COMPLETION
==============================================================================

Archive policy, resumable tools, verified archives, indexes, off-device protection, restore drills, retention, cleanup gates, documentation, and Owner acceptance are complete.

Plans, folders, elapsed time, questionnaires, and roadmap connections do not
increase Blue Current. Progress changes require accepted evidence against this
weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Verified intact archives and restore maps.
- Declared verification methods.
- Sources preserved.
- No premature deletion.

Comfortably Functional / Purple:
- Checkpointed archives.
- Searchable indexes.
- Off-device protection.
- Restore drills and cleanup reviews.

First Green work target / pause point:
- Finish evidence-backed copy-first migration without deletion.
- Pause for Owner and portfolio review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Policy, verification taxonomy, retention, and deletion gates
Weight: 12%
ETUC: 45–80 active hours

Deliverables:
- Define Full SHA-256, tiered, metadata, sampled, partial, and unverified methods.
- Define retention, unresolved-file, and deletion-approval policy.

Evidence gate:
- Owner approves policy.
- Methods are never treated as equivalent.

Stop / return condition:
- HOLD on ambiguous verdicts or automatic cleanup.
PHASE 02 — Authoritative inventory, source maps, and dependency discovery
Weight: 12%
ETUC: 55–95 active hours

Deliverables:
- Inventory legacy roots, relative paths, sizes, hashes where feasible, dependencies, junctions, and conflict areas.

Evidence gate:
- Inventory completeness report passes.
- No overwrite guesses.

Stop / return condition:
- Return if unresolved material is not preserved honestly.
PHASE 03 — Checkpointed copy, manifest, hashing, and verification tools
Weight: 14%
ETUC: 75–130 active hours

Deliverables:
- Implement resumable copy/hash checkpoints, progress/ETUC, tiered verification, and evidence packages.

Evidence gate:
- Resume after interruption.
- Successful copy work is not repeated unnecessarily.

Stop / return condition:
- HOLD on endless non-checkpointed hashing or destructive sync.
PHASE 04 — Evidence-backed root archives and migration continuity
Weight: 16%
ETUC: 90–155 active hours

Deliverables:
- Create copy-first archives, source preservation, migration reports, and compatibility maps.

Evidence gate:
- Included roots are verified using declared methods.
- No deletion.
- Restore map complete.

Stop / return condition:
- Return on byt

CROSS-DEVICE ROUTER ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: F.O.U.R. → Forgey Foundry
Logical role: Secure cross-device transport and inventory synchronization engine
Canonical source candidate: D:\THE SPARK\FOUR\03_Forgey_Foundry\01_Engines\05_Cross_Device_Router
Weight status: Proposed 10% of Forgey Foundry; provisional pending parent rebalancing.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Provide the secure transport-only fabric connecting authorized Forgey devices, synchronizing persistent inventory and carrying signed messages, heartbeats, receipts, results, and evidence references without deciding or executing work.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

Approved devices securely enroll, connect outbound, synchronize inventory, exchange durable/idempotent messages with truthful lifecycle and receipts, recover from outages, rotate/revoke credentials, and operate on a production-grade portable backend with Owner acceptance.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- Router is secure transport only and never authorizes or executes application work.
- Prove the protocol with a deterministic local fixture backend before Cloudflare deployment.
- One-time enrollment requires Owner approval, stable device identity, credentials, role, namespace, recovery/rotation, and evidence.
- Only safe idempotent non-destructive commands may queue offline with expiry/revalidation.
- v1 proof uses Doonchy and Roy device fixtures before real Roy enrollment.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

Two fixture devices enroll, inventory synchronizes, signed safe messages deliver with receipts, outages/reconnect work, and dangerous offline commands are rejected.

Comfortably Functional / Purple:

Reliable daily multi-device operation with mature credential lifecycle, recovery, observability, bounded queues, portable backend, and low support burden.

First Green work target / pause point:

Complete two-device fixture transport and inventory synchronization without live watcher execution, then pause.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==============================================================================

01. Goal, protocol, and transport boundary                  10%   30–55h
02. Identity and device enrollment                          12%   45–80h
03. Device client                                           13%   55–95h
04. Deterministic fixture backend                           12%   50–90h
05. Persistence, queues, and idempotency                    10%   

F.O.U.R. — DEVICE INSTALLATION AND MULTI-PC DEPLOYMENT ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R. (cross-cutting program)
Component type: Device deployment, installation, configuration, and operations program
Proposed parent allocation: No separate portfolio weight
Numerical Blue Current rule: Use 18% only as provisional F.O.U.R./Foundry readiness for a controlled device test. It is not a device-health or installation-completion score.
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the repeatable secure process for installing, enrolling, configuring, updating, verifying, recovering, and retiring the correct F.O.U.R. systems on approved computers.

Plain-language purpose:
The safe process for putting the right F.O.U.R. parts on each family computer.

Explicitly not:
One identical image for every PC, permission to copy all data everywhere, or automatic production cutover.

==============================================================================
100% COMPLETION
==============================================================================

The complete device program, website bootstrap, Resend verification, Manual/AI-guided onboarding, F.O.U.R. Desktop authority, InstaDater transactions, role-based packages, enrollment, updates, recovery, offline behavior, and Owner acceptance are complete.

Plans, folders, elapsed time, questionnaires, and roadmap connections do not
increase Blue Current. Progress changes require accepted evidence against this
weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- One-device core install with inventory, rollback, offline operation, and no legacy damage.
- F.O.U.R. Desktop catalog and lifecycle authority.
- InstaDater execution evidence.

Comfortably Functional / Purple:
- Reliable Doonchy/Roy operation.
- Staged updates.
- Remote visibility/control where approved.
- Recovery and low support burden.

First Green work target / pause point:
- Approve device-role/install matrices and complete a no-change preflight/dry-run.
- Pause for Owner and portfolio review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Device roles, identities, hardware profiles, and install matrices
Weight: 12%
ETUC: 55–95 active hours

Deliverables:
- Create stable device IDs, Doonchy/Roy/future role matrix, hardware/storage profiles, and per-device install sets.

Evidence gate:
- Owner approves matrices.
- No identical-all-PC assumption.

Stop / return condition:
- HOLD on unknown hardware, roles, paths, or install sets.
PHASE 02 — Website installer, Resend verification, and onboarding choice
Weight: 14%
ETUC: 65–110 active hours

Deliverables:
- Build installer download page, Resend email verification, Manual route, AI-guided route, and privacy disclosure.

Evidence gate:
- Verified-email and failure tests pass.
- No installation starts before route confirmation.

Stop / return condition:
- Return if verification, privacy, or account recovery is unclear.
PHASE 03 — InstaDater bootstrap and F.O.U.R. Desktop authority
Weight: 16%
ETUC: 80–135 active hours

Deliverables:
- Bootstrap InstaDater.
- Install F.O.U.R. Desktop.
- Grant F.O.U.R. Desktop user-facing install/update authority.
- Expose repair, rollback, inventory, and lifecycle evidence.

Evidence gate:
- Clean fixture install and rollback pass.
- F.O.U.R. Desktop can authorize/initiate lifecycle transactions.
- InstaDater executes them deterministically.

Stop / return condition:
- HOLD if F.O.U.

F.O.U.R. — FORGEY AIO ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R.
Component type: AI platform and application family
Proposed parent allocation: 20% proposed; inactive until full F.O.U.R. rebalance
Numerical Blue Current rule: Preserve the current DadaTracker numerical value until existing training/tracker evidence is reconciled against this roadmap.
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the complete local-and-cloud AI platform for models, chat, projects, memory, files, vision, tools, evaluations, and safe cross-app help.

Plain-language purpose:
The one personal AI that learns approved information and helps the user do everything better across F.O.U.R.

Explicitly not:
Master Engine, Forgey Control, unrestricted infrastructure authority, or a promise that every model fits current hardware.

==============================================================================
100% COMPLETION
==============================================================================

Forgey AIO is fully local/cloud capable, secured, evaluated, documented, installable, recoverable, hardware-aware, cross-app integrated, Owner-accepted, and preserves all training/model evidence.

Plans, folders, elapsed time, questionnaires, and roadmap connections do not
increase Blue Current. Progress changes require accepted evidence against this
weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Reliable local chat/projects.
- Model selection and files.
- Inspectable SQLite3 memory.
- Supported coding/vision.
- Privacy and recovery.

Comfortably Functional / Purple:
- Polished multi-model assistant.
- Evaluations and multimodal tools.
- Cross-app personal context.
- Hardware optimization.
- Optional cloud availability.

First Green work target / pause point:
- Approve canonical architecture and run one evaluated local-model workflow without moving model blobs.
- Pause for Owner and portfolio review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Existing AIO roadmap, training, source, and migration-boundary reconciliation
Weight: 10%
ETUC: 55–95 active hours

Deliverables:
- Preserve training goals, datasets, adapters, model ladder, lifecycle, and prior plans.
- Lock D:\05_Forgey_AI versus canonical target boundaries.
- Define the migration-after-training-and-packaging gate.

Evidence gate:
- No AIO status is lost.
- Paths and hashes are recorded.
- No physical migration occurs.

Stop / return condition:
- HOLD if training truth or model blobs cannot be preserved.
PHASE 02 — Providers, models, routing, hardware profiles, and resource policy
Weight: 14%
ETUC: 90–155 active hours

Deliverables:
- Create provider/model/version registry, visible privacy/cost/resource route, fallback, queue policy, and hardware profiles.

Evidence gate:
- No silent cloud route.
- Target-hardware evaluations pass.
- Shared memory is never reported as dedicated VRAM.

Stop / return condition:
- HOLD on hardware overclaims or hidden cloud upload.
PHASE 03 — Unified chat, projects, coding, files, and cross-app personal context
Weight: 16%
ETUC: 100–175 active hours

Deliverables:
- Implement private chat, project workspaces, coding, document analysis, history, and cross-app person context.

Evidence gate:
- Project isolation passes.
- Context provenance is visible.
- No secret/system-prompt leakage.

Stop / return condition:
- Return if cross-user or cross-project context leaks.
PHASE 04 — Broad file and tool c

FORGEY CONTROL ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: F.O.U.R. → Forgey Foundry
Logical role: Sole Foundry-wide authorization and control engine
Canonical source candidate: D:\THE SPARK\FOUR\03_Forgey_Foundry\01_Engines\06_Forgey_Control
Weight status: Proposed 12% of Forgey Foundry; provisional pending parent rebalancing.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Build the only Foundry-wide authorized controller: automatically discover valid installed components and profiles, present truthful state, obtain approvals, issue bounded commands locally/remotely, preserve an SQLite command ledger, and review evidence without executing target internals.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

All approved Foundry items are automatically inventoried, truthfully visible, securely and role-appropriately controllable, fully audited in a recoverable SQLite command/evidence ledger, integrated with Router/Desktop/InstaDater, and Owner-accepted across approved devices.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- Forgey Control remains the sole Foundry-wide authorized controller.
- Every valid installed component/profile appears in persistent inventory before first run.
- /status all includes components, apps, profiles, devices, updater, and transport with freshness and blockers.
- Control keeps a secure core/API and minimal maintenance UI; Forgey Desktop is the polished visual center.
- Dangerous commands never queue offline.
- Command records must be saved in a SQLite3 database.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

Automatically discover fixture items, display truthful Installed/Stopped and runtime state, authorize safe commands, reject invalid/dangerous commands, and record complete SQLite-backed command evidence.

Comfortably Functional / Purple:

Reliable daily multi-device control with mature roles, diagnostics, approvals, recovery, Desktop integration, command history, and easy evidence review.

First Green work target / pause point:

Automatic persistent fixture inventory with truthful Installed/Stopped/runtime state and SQLite command records, then pause.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==============================================================================

01. Source reconciliation and baseline                      10%   35–65h
02. Authority, identity, and command contracts              12%   45–80h
03. Persistent inventory and automatic discovery            15%   55–95h
04. SQLite command and audit ledger                         12

FORGEY DESKTOP ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R. → Forgey Foundry
Component type: Desktop application and visual command center
Current version truth: v0.0.1 exists; long-term product remains incomplete
Canonical source: REQUIRES CONFIRMATION
Implementation authority: SEPARATE FUTURE AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build Forgey Desktop as the polished, accessible, truthful visual command center
where Doonchy and approved family users can understand Forgey Foundry, review
portfolio progress, inspect devices/components/profiles, handle approvals,
review evidence and diagnostics, and safely request bounded actions through
Forgey Control without duplicating runtime, authorization, routing, updating,
or component logic.

==============================================================================
100% COMPLETION
==============================================================================

100% means the complete approved Forgey Desktop product is implemented,
secured, tested, documented, installable, updateable, repairable, recoverable,
accessible, performant on approved Windows hardware, integrated through
versioned contracts, and Owner-accepted for daily use.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Official components and profiles are visible.
- Blue/Amber/Purple/Green values have source, freshness, confidence, and
  evidence.
- Fixture approvals and bounded Control requests work safely.
- Important failures and holds are visible.
- Evidence and rollback paths are reviewable.

Comfortably Functional / Purple:
- Reliable daily multi-device command-center workflows.
- Polished navigation, notifications, diagnostics, accessibility,
  customization, offline behavior, recovery, and low-friction evidence review.

First Green target / pause point:
- Complete a fixture-only portfolio dashboard using approved progress and
  explicit installed/running/connected/controllable/released/healthy labels.
- Pause for full portfolio review before live Control integration.

Component allocation:
- Questionnaire proposal: 7% of Forgey Foundry.
- Do not use this in the official parent calculation until the entire Foundry
  child-weight table is rebalanced to 100%.

Blue Current:
- No new percentage is established by this roadmap.
- v0.0.1 and existing UI concepts remain evidence inputs only.

==============================================================================
WEIGHTED PHASES
==============================================================================


PHASE 01 — Product, source, and authority boundary lock
Weight: 10%
ETUC: 22–40 active hours
Dependencies: Owner planning baseline and current Foundry architecture.

Deliverables:
- Confirm canonical source and installed-runtime locations.
- Lock Forgey Desktop versus Forgey Control, Master Engine, Router, InstaDater, DadaTracker, and component boundaries.
- Define users, roles, privacy, telemetry, and release terminology.

Evidence gate:
- Owner-reviewed product/authority matrix.
- Source candidates and version truth are documented.

Stop / return condition:
- HOLD on duplicate control authority or unresolved canonical source.
PHASE 02 — Information architecture and family-friendly navigation
Weight: 15%
ETUC: 45–80 active hours
Dependencies: Phase 01.

Deliverables:
- Home screen, portfolio, component, profile, device, approvals, evidence, diagnostics, settings, and help navigation.
- Family-friendly summaries plus technical drill-down.
- Responsive desktop and compact layouts.

Evidence gate:
- Usability review with family members.
- Keyboard, screen-reader, and mobile-layout evidence.

Stop / return condi

FORGEY FOUNDRY PLATFORM ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: F.O.U.R. → Forgey Foundry
Logical role: Component platform and product family
Canonical source candidate: D:\THE SPARK\FOUR\03_Forgey_Foundry
Weight status: Proposed 8% of Forgey Foundry; provisional until Foundry weights are rebalanced.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Define how Foundry engines, apps, profiles, tools, tests, docs, packages, releases, and devices form one coherent platform while preserving every component's separate authority and responsibility.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

Every approved component follows stable identity, manifest, discovery, compatibility, lifecycle, evidence, packaging, progress, and release-set rules; the platform is secure, documented, recoverable, installed on approved devices, and Owner-accepted.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- An official Foundry component requires approved identity, canonical location, manifest, owner, version, interfaces, evidence, tests, lifecycle metadata, and roadmap classification.
- Valid installed components register automatically; manual per-component pairing is rejected.
- v1 remains Owner-approved first-party only while a future signed extension path is designed.
- Release sets reference independently versioned compatible releases rather than forcing one version.
- Only official portfolio components/apps/profiles receive chart entries.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

Every core component has a valid manifest, canonical location, owner, compatibility record, basic automatic fixture discovery, and truthful progress/status.

Comfortably Functional / Purple:

Reliable multi-device daily operation with automatic inventory, coordinated lifecycle requests, diagnostics, rollback, and polished visual status.

First Green work target / pause point:

Approve component manifest v1 and automatic fixture inventory, then pause for portfolio review.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==============================================================================

01. Platform goal and boundary lock                         10%   18–32h
02. Component model and registry                            15%   35–65h
03. Manifest and automatic discovery                        20%   55–95h
04. Compatibility and release sets                          15%   45–80h
05. Lifecycle and InstaDater integration                    15%   50–90h
06. Portfolio and Desktop presentation                      10%   3

FORGEY GLOBAL ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R. → Forgey Foundry
Component type: Protected high-trust watcher profile
Runtime owner: Master Engine
Control authority: Forgey Control
Current version truth: Target profile; not accepted installed or released
Canonical source: REQUIRES CONFIRMATION
Implementation authority: SEPARATE FUTURE AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build Forgey Global as the protected general-purpose watcher profile that can
understand broad explicitly approved areas of the computer, help organize and
maintain work, use approved local AI and memory, and execute only within visible
modes, least-privilege permissions, policy, and fresh authorization while
producing reconstructable evidence and preserving Forgey Local until accepted
cutover.

==============================================================================
100% COMPLETION
==============================================================================

100% means Forgey Global is fully defined, generated, validated, isolated,
secured, tested, documented, installable, updateable, repairable, recoverable,
integrated through approved contracts, proven by fixture and read-only shadow
comparison, staged safely onto approved devices, and Owner-accepted after
rollback evidence.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- A generated fixture profile can observe approved roots.
- It can plan, request approval, make bounded fixture changes, produce evidence,
  stop, recover, and remain isolated.
- Visibility and write authority are distinct.
- No silent escalation occurs.

Comfortably Functional / Purple:
- Reliable daily assistance across approved projects/devices with mature
  context, diagnostics, bounded automation, local AI, memory, recovery,
  handoffs, and low-friction Control/Desktop workflows.

First Green target / pause point:
- Complete the fixture profile and read-only shadow comparison against Forgey
  Local.
- Pause for evidence review before any live cutover.

Component allocation:
- Questionnaire proposal: 5% of Forgey Foundry.
- Do not use this in the official parent calculation until the entire Foundry
  child-weight table is rebalanced to 100%.

Blue Current:
- New Forgey Global remains Not implemented / Not verified.
- Legacy Forgey Local behavior is evidence, not Forgey Global completion.

==============================================================================
WEIGHTED PHASES
==============================================================================


PHASE 01 — Goal, legacy behavior, source, and boundary inventory
Weight: 10%
ETUC: 30–55 active hours
Dependencies: Owner planning baseline and legacy Forgey Local evidence.

Deliverables:
- Inventory Forgey Local behavior and current evidence.
- Confirm canonical profile source/runtime/data candidates.
- Lock Forgey Global versus Master Engine, Control, Router, InstaDater, Desktop, and component ownership.

Evidence gate:
- Behavior inventory and source report.
- Owner-reviewed profile boundary.

Stop / return condition:
- HOLD on unresolved source or duplicate runtime/control responsibilities.
PHASE 02 — Profile contract, identity, configuration, and manifests
Weight: 12%
ETUC: 45–80 active hours
Dependencies: Shared Schemas and Watcher Profile SDK direction.

Deliverables:
- Profile identity, owner, roots, exclusions, actions, modes, providers, memory, evidence, compatibility, and lifecycle contracts.
- Deterministic configuration and manifest validation.

Evidence gate:
- Positive and negative fixture validation.
- No secret-bearing configuration.

Stop / return condition:
- Return if visibility and write

F.O.U.R. — FORGEY UTILITIES ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R.
Component type: Reusable utility family
Proposed parent allocation: 8% proposed
Numerical Blue Current rule: Preserve the current DadaTracker numerical value until every legacy utility is inventoried and evidence-mapped.
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the governed family of reusable F.O.U.R. utilities that do not belong to one product and can be safely cataloged, installed, updated, documented, and retired.

Plain-language purpose:
The shared toolbox for useful scripts and small apps across F.O.U.R.

Explicitly not:
A dumping ground, duplicate component source, hidden production dependency, or unreviewed one-off scripts.

==============================================================================
100% COMPLETION
==============================================================================

The complete utility catalog is reconciled, secured, tested, consistently packaged, documented, installable, recoverable, versioned, maintained, and safely retired with Owner acceptance.

Plans, folders, elapsed time, questionnaires, and roadmap connections do not
increase Blue Current. Progress changes require accepted evidence against this
weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Authoritative catalog.
- High-value read-only/low-risk tools.
- Safety standards.
- Install and rollback.

Comfortably Functional / Purple:
- Curated toolbox.
- Consistent UX/docs/updates.
- Diagnostics and compatibility.
- Clean retirement.

First Green work target / pause point:
- Complete the authoritative inventory and classify every legacy utility.
- Pause for Owner and portfolio review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Authoritative inventory and classification
Weight: 18%
ETUC: 55–95 active hours

Deliverables:
- Inventory legacy utilities with hashes, owners, dependencies, and status.
- Classify utility versus product tool versus Foundry Developer Tool.

Evidence gate:
- Every discovered utility is classified.
- No duplicate ownership.

Stop / return condition:
- HOLD if an active utility remains unowned or path truth is unresolved.
PHASE 02 — Utility standards, safety, dry-run, schemas, and UX
Weight: 14%
ETUC: 45–80 active hours

Deliverables:
- Create input/output, evidence, dry-run, permission, rollback, version, packaging, and UX standards.

Evidence gate:
- Negative tests pass.
- Dry-run performs no writes.
- Standards are approved.

Stop / return condition:
- HOLD on destructive defaults or hidden dependencies.
PHASE 03 — Core read-only and low-risk utility catalog
Weight: 18%
ETUC: 70–120 active hours

Deliverables:
- Implement inventory, hash/manifest, comparison, path validation, evidence packaging, backup verification, and diagnostics.

Evidence gate:
- Deterministic fixture results.
- No source mutation.
- Examples are documented.

Stop / return condition:
- Return if utilities disagree on truth.
PHASE 04 — Packaging, installation, update, repair, and compatibility
Weight: 14%
ETUC: 55–95 active hours

Deliverables:
- Create manifests, shared package format, compatibility/deprecation/migration rules, and InstaDater integration.

Evidence gate:
- Tamper rejection passes.
- Install/rollback tests pass.
- Versions are truthful.

Stop / return condition:
- HOLD if provenance or rollback is missing.
PHASE 05 — Cross-family integration and reusable UX
Weight: 14%
ETUC

FOUNDRY DEVELOPER TOOLS ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R. → Forgey Foundry
Component type: Developer and operator toolset
Proposed parent allocation: 4% of Forgey Foundry
Current Blue baseline: 55% PROVISIONAL — preserved, not increased by this roadmap
Canonical source: REQUIRES CONFIRMATION under D:\THE SPARK\FOUR\03_Forgey_Foundry
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the complete approved Foundry Developer Tools capability supporting reliable inspection, validation, diagnostics, reproducible build and packaging, migration, evidence, maintenance, recovery, and release without becoming a production runtime or hidden authority layer.

Plain-language purpose:
The reusable Foundry toolkit for inspecting, validating, building, packaging, diagnosing, migrating, and safely maintaining Foundry systems.

Explicitly not:
A production engine, controller, updater, fixture orchestrator, or collection of unlogged destructive scripts.

==============================================================================
100% COMPLETION
==============================================================================

The complete long-term tool catalog is reconciled, secured, tested, documented, installable, recoverable, versioned, packaged, evidence-producing, and Owner-accepted on approved Windows hardware.

Folder creation, plans, elapsed time, or roadmap existence do not equal
completion. Blue Current changes only from accepted evidence against the
approved weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Canonical catalog of active and archived tools.
- Validated read-only inventory, hashing, manifest, hierarchy, package, evidence, and diagnostic tools.
- Approved safety standard and mandatory dry-run behavior for writes.
- Truthful evidence and deterministic failure reporting.

Comfortably Functional / Purple:
- Reliable maintainer workbench and command catalog.
- Safe write, repair, migration, and cleanup tools with previews and rollback.
- Reproducible builds, validated packages, compatibility checks, and easy evidence.
- Clear diagnostics, documentation, and support workflows.

First Green work target / pause point:
- Approve the tool safety standard and validate the core read-only toolkit.
- Pause at this checkpoint for portfolio and evidence review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Catalog, source reconciliation, and authority boundaries
Weight: 12%
ETUC: 35–60 active hours

Dependencies:
- Authoritative Foundry hierarchy
- Existing script/tool inventories
- Owner-approved component boundaries

Deliverables:
- Canonical tool catalog
- Source/runtime/package/archive separation map
- Ownership and dependency matrix
- One-off classification and archive policy

Evidence gate:
- Complete tool inventory with hashes
- No duplicate runtime, updater, fixture, or controller responsibility
- Owner-reviewed source/boundary report

Stop / return condition:
- HOLD if canonical source or tool ownership remains ambiguous
- Return if active workflows silently depend on unclassified one-off scripts
PHASE 02 — Tool safety standard, dry-run, authorization, and rollback
Weight: 16%
ETUC: 45–80 active hours

Dependencies:
- Phase 01 catalog
- Forgey Control authorization model
- Shared evidence conventions

Deliverables:
- Read-only/write classification
- Mandatory dry-run contract
- Exact proposed-action previews
- Risk/approval/expiry rules
- Backup-first

FOUNDRY DOCUMENTATION SYSTEM ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R. → Forgey Foundry
Component type: Documentation, knowledge, and operating-instruction system
Proposed parent allocation: 2% of Forgey Foundry
Current Blue baseline: 80% PROVISIONAL — preserved, not increased by this roadmap
Canonical source: REQUIRES CONFIRMATION under D:\THE SPARK\FOUR\03_Forgey_Foundry
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the complete approved Foundry Documentation System capability that keeps architecture, product, developer, operator, security, installation, recovery, release, evidence, and handoff knowledge accurate, audience-specific, searchable, tested, versioned, and coupled to real source and release truth.

Plain-language purpose:
The trusted Foundry documentation and knowledge system that helps the Owner, family, operators, developers, installers, recovery staff, and future maintainers understand and safely use the system.

Explicitly not:
Runtime truth, a substitute for tests, unreviewed marketing, or auto-published AI text without evidence and human review.

==============================================================================
100% COMPLETION
==============================================================================

The complete long-term documentation system is implemented, secured, tested, indexed, searchable, rendered, audience-specific, installable, recoverable, release-coupled, freshness-checked, and Owner-accepted.

Folder creation, plans, elapsed time, or roadmap existence do not equal
completion. Blue Current changes only from accepted evidence against the
approved weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Canonical documentation index and current architecture map.
- Trustworthy install, run, recovery, boundary, progress-method, and release documentation.
- Tested or visibly labeled executable examples.
- Stale and superseded documents linked to replacements.

Comfortably Functional / Purple:
- Polished audience-specific guides.
- Automated freshness, path, link, diagram, and example validation.
- Search, diagrams, handoffs, changelogs, support playbooks, and release coupling.
- Reliable documentation maintenance and recovery workflow.

First Green work target / pause point:
- Create the canonical documentation index and validate current architecture and path references.
- Pause at this checkpoint for portfolio and evidence review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Documentation standard, canonical index, and source reconciliation
Weight: 16%
ETUC: 40–70 active hours

Dependencies:
- Authoritative Foundry hierarchy
- Existing docs/handoffs
- HQ governance truth

Deliverables:
- Canonical documentation index
- Audience taxonomy
- Document status/version/freshness standard
- Source and ownership map
- Stale/superseded/history policy

Evidence gate:
- Broken links and stale path scan
- Owner-reviewed index
- Every current document has owner, audience, status, source, and replacement rules

Stop / return condition:
- HOLD on multiple current truths, missing ownership, or unresolved canonical locations
PHASE 02 — Architecture, hierarchy, authority, and integration documentation
Weight: 16%
ETUC: 45–80 active hours

Dependencies:
- Phase 01
- Accepted architecture and Shared Schemas

Deliverables:
- The Spark/F.O.U.R./Foundry hierarchy
- Component ownership maps
- Control/runtime/router/updater/Desktop boundari

FOUNDRY TEST AND FIXTURE SYSTEM ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R. → Forgey Foundry
Component type: Shared test, fixture, simulation, and evidence system
Proposed parent allocation: 4% of Forgey Foundry
Current Blue baseline: 45% PROVISIONAL — preserved, not increased by this roadmap
Canonical source: REQUIRES CONFIRMATION under D:\THE SPARK\FOUR\03_Forgey_Foundry
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the complete approved Foundry Test and Fixture System capability that proves Foundry behavior safely through strict fixture/live separation, unit and contract harnesses, component fixtures, integration labs, negative tests, recovery, security, performance, and truthful release gates.

Plain-language purpose:
The shared safe laboratory for proving that Foundry components work together without touching live family systems or presenting fixture data as live truth.

Explicitly not:
Production runtime data, fake live state, a replacement for component-owned tests, or a mechanism for hiding flaky or skipped failures.

==============================================================================
100% COMPLETION
==============================================================================

The complete long-term test and fixture system is implemented, isolated, secured, documented, installable, recoverable, evidence-producing, integrated across approved components, and Owner-accepted with representative security, recovery, performance, multi-device, and release-gate proof.

Folder creation, plans, elapsed time, or roadmap existence do not equal
completion. Blue Current changes only from accepted evidence against the
approved weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Hard fixture/live separation.
- Common unit, contract, fixture, and result harnesses.
- Core component fixtures with deterministic reset and recovery.
- First cross-component scenario with truthful aggregate verdict.

Comfortably Functional / Purple:
- Routine reliable release gates across components.
- Security, negative, recovery, multi-device, performance, and disaster testing.
- Flaky-test quarantine with visible ownership and deadlines.
- Reproducible fixture environments and evidence bundles.

First Green work target / pause point:
- Prove fixture/live separation and run the first cross-component fixture scenario.
- Pause at this checkpoint for portfolio and evidence review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Fixture/live standard, identities, and fail-closed separation
Weight: 14%
ETUC: 45–80 active hours

Dependencies:
- Authoritative Foundry hierarchy
- Component boundary matrix
- Security and identity standards

Deliverables:
- Distinct fixture/live roots, identities, ports, storage, credentials, banners, and guards
- Common fixture manifest
- Fixture/live detection library
- No-live-path policy

Evidence gate:
- Attempts to use live paths or credentials fail closed
- Fixture UI is visibly labeled
- No production data appears in fixtures

Stop / return condition:
- HOLD on ambiguous environment identity or any path from fixture to live targets
PHASE 02 — Unit, contract, and common result harnesses
Weight: 14%
ETUC: 55–95 active hours

Dependencies:
- Shared Schemas
- Component-owned unit tests
- Fixture identity standard

Deliverables:
- Common test result schema
- Contract harnesses
- Mock/stub conventions
- Flaky-test quarantine policy
- Deterministic see

F.O.U.R. REALM ROADMAP — HIERARCHY/WEIGHT REVISION
Roadmap version: 0.1.1
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Supersedes: v0.1.0 parent-weight statements only
Implementation authority: NONE

Newest parent hierarchy:

The Spark
├── F.O.U.R. — 90%
└── InstaDater — 10%

F.O.U.R. remains the all-in-one realm containing HQ, LPS, Forgey AIO, Forgey
Foundry, Utilities, Future Families, and Archive/Continuity.

Forgey AIO remains inside F.O.U.R.

The v0.1.0 F.O.U.R. Realm roadmap remains current for mission, internal family
boundaries, F.O.U.R. Desktop, identity, health presentation, storage,
deployment, and evidence. Only the former assumption that F.O.U.R. is 100% of
The Spark is superseded.

Required roadmap consequence:
- Treat top-level InstaDater as an external lifecycle dependency.
- Remove InstaDater implementation work from F.O.U.R.-internal weighted
  completion where double-counting would occur.
- Add The Spark-level integration gates between F.O.U.R. Desktop and
  InstaDater.
- Recalculate The Spark overall progress as:
  90% × F.O.U.R. progress + 10% × InstaDater progress,
  subject to accepted roadmaps/evidence and any approved hard gates.

This revision does not change Blue Current by itself.

F.O.U.R. — FUTURE FAMILIES ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R.
Component type: Portfolio incubation and future namespace
Proposed parent allocation: 2% proposed
Numerical Blue Current rule: Keep the numerical tracker at 0% until the intake-governance capability itself has accepted evidence; a placeholder folder is not progress.
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Build the governed incubation area for truly new F.O.U.R. families that cannot fit existing families and pass strict Owner-approved intake.

Plain-language purpose:
The reserved place for future major product families, not random projects.

Explicitly not:
A junk drawer, automatic family creator, or home for apps/components that fit existing families.

==============================================================================
100% COMPLETION
==============================================================================

The intake, scoring, sandbox, prototype, promotion, weight-rebalance, retirement, security, documentation, and continuity system is fully implemented and Owner-accepted.

Plans, folders, elapsed time, questionnaires, and roadmap connections do not
increase Blue Current. Progress changes require accepted evidence against this
weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- One repeatable intake gate.
- 9.5/10 scorecard.
- Isolated prototype process.
- Zero-active-family truth.

Comfortably Functional / Purple:
- Reliable incubation.
- Portfolio comparison.
- Promotion workflow.
- Clean retirement.

First Green work target / pause point:
- Approve the family intake scorecard and zero-active-family baseline.
- Pause for Owner and portfolio review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Intake standard, 9.5/10 scorecard, and zero-active-family baseline
Weight: 18%
ETUC: 40–70 active hours

Deliverables:
- Create intake template, 9.5/10 scorecard, evidence requirements, and zero-active-family register.

Evidence gate:
- Scorecard is reviewed.
- No active family is falsely claimed.

Stop / return condition:
- HOLD if family criteria can be bypassed.
PHASE 02 — Namespace, collision, architecture, and portfolio analysis
Weight: 18%
ETUC: 45–80 active hours

Deliverables:
- Implement naming/collision checks, existing-family fit, authority/data/integration boundaries, and weight impact.

Evidence gate:
- Proposal proves it cannot be an app/component.
- No duplicate authority.

Stop / return condition:
- Reject if an existing family can own it.
PHASE 03 — Isolated incubation sandbox and capacity limits
Weight: 16%
ETUC: 50–90 active hours

Deliverables:
- Enforce one-major-incubation default, no live secrets/data/authority, fixture namespace, and resource ceilings.

Evidence gate:
- Sandbox separation tests pass.
- No portfolio progress is inherited.

Stop / return condition:
- HOLD on live-data reach or abandoned-parallel risk.
PHASE 04 — Prototype evidence and comparative evaluation
Weight: 18%
ETUC: 65–115 active hours

Deliverables:
- Build bounded prototype and user/value, security/privacy/cost, and alternatives evidence.

Evidence gate:
- 9.5/10 threshold is met with evidence.
- No unsupported claims.

Stop / return condition:
- Return or retire if evidence weakens.
PHASE 05 — Owner promotion, weight rebalance, migration, and release gate
Weight: 16%
ETUC: 55–100 active hours

Deliverables:
- Require Owner sponsorship, approved roadmap, full weight rebalance, c

INSTADATER ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: The Spark
Logical role: The Spark-wide unified installation, update, repair, migration, and rollback engine
Canonical source candidate: Current candidate: D:\THE SPARK\FOUR\03_Forgey_Foundry\01_Engines\01_InstaDater; logical top-level source placement pending
Weight status: Owner-selected 10% of The Spark; F.O.U.R. becomes 90%.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Build the one and only transaction-safe lifecycle engine for all of The Spark—including F.O.U.R., LPS, Forgey AIO, Forgey Foundry, Utilities, applications, components, profiles, clients, and itself—controlled through the future F.O.U.R. Desktop rather than Forgey Desktop.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

All approved The Spark software can be installed, updated, repaired, migrated, rolled back, verified, staged, and recovered through one secure manifest-driven engine with manual-by-default updates, protected 30-day backup retention, self-update recovery, multi-device evidence, and Owner acceptance.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- InstaDater is the one and only installer/updater/repair/migration/rollback engine for all of The Spark.
- Updates are not automatic by default.
- Packages require hashes immediately and signed release manifests before production.
- Transactions use atomic replacement where possible, otherwise journals/staging/backups/verification/rollback.
- InstaDater may self-update only through staged dual-version/self-test with external rollback.
- Forgey Desktop must not control InstaDater; the future F.O.U.R. Desktop is the approved human control surface.
- InstaDater becomes a top-level The Spark system weighted at 10%; F.O.U.R. becomes 90%.
- Backups are retained for 30 days to avoid unnecessary storage use.
- Updates are not automatic by default.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

Install, update, repair, and roll back fixture versions of at least two components with complete evidence and no live damage.

Comfortably Functional / Purple:

Reliable multi-device lifecycle management with staged rollout, health gates, self-repair, diagnostics, protected cleanup, fast rollback, and F.O.U.R. Desktop control.

First Green work target / pause point:

Complete a fixture update and forced-failure rollback with exact evidence and 30-day retention simulation, then pause.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==============================================================================

01. Top-level

F.O.U.R. — LPS PORTFOLIO RECONCILIATION ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R.
Component type: Family operating-system application family
Proposed parent allocation: 24% proposed
Numerical Blue Current rule: Preserve the current DadaTracker numerical value until the dedicated LPS roadmap and implementation evidence are audited against this portfolio roadmap.
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Complete the private family operating system for planning, calendars, tasks, habits, goals, nine life pillars, guides, coordination, approved AI, and automation.

Plain-language purpose:
The family app that helps everyone manage life privately in one place.

Explicitly not:
Foundry infrastructure, a generic business CRM, unrestricted automation runtime, or advertising-driven family-data product.

==============================================================================
100% COMPLETION
==============================================================================

LPS is fully implemented, secured, tested, accessible, cost-controlled, documented, multi-device reliable, recoverable, installable, and Owner/family accepted while preserving its dedicated roadmap and MongoDB truth.

Plans, folders, elapsed time, questionnaires, and roadmap connections do not
increase Blue Current. Progress changes require accepted evidence against this
weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Profiles and role permissions.
- Calendar, tasks, habits, goals, and pillars.
- Notifications and backups.
- Stable daily planning.

Comfortably Functional / Purple:
- Polished coordination.
- Guides/templates and evidence-based AI.
- Analytics and multi-device reliability.
- Accessible low-support family UX.

First Green work target / pause point:
- Reconcile the dedicated LPS roadmap, lock the daily MVP, and prove one family daily workflow end to end.
- Pause for Owner and portfolio review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Existing LPS roadmap, source, runtime, and MongoDB reconciliation
Weight: 10%
ETUC: 35–65 active hours

Deliverables:
- Reconcile the dedicated LPS roadmap and current implementation without replacing valid prior work.
- Lock canonical source, active environment, MongoDB, backups, and release truth.
- Create an evidence-to-capability matrix.

Evidence gate:
- Current source/build/runtime evidence is reproduced.
- MongoDB ownership and restore path are documented.
- No valid LPS history is lost.

Stop / return condition:
- HOLD if multiple roadmaps claim current truth or the active environment is unclear.
PHASE 02 — Family identity, roles, child privacy, and nine-pillar model
Weight: 14%
ETUC: 65–110 active hours

Deliverables:
- Define Owner, parent, child, and delegated roles.
- Lock nine-pillar schemas, names, permissions, cross-links, retention, sharing, and export rules.

Evidence gate:
- Permission and privacy negative tests pass.
- Child-safety review passes.
- Schema/version tests pass.

Stop / return condition:
- HOLD on over-broad access or unresolved pillar boundaries.
PHASE 03 — Daily planning core and first end-to-end workflow
Weight: 18%
ETUC: 85–145 active hours

Deliverables:
- Build dashboard, calendar, tasks, habits, goals, progress, reminders, and backup.
- Complete the morning/day planning workflow.

Evidence gate:
- A family profile completes the full workflow.
- State survives restart and restore.
- No commitments are inven

MASTER ENGINE ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: F.O.U.R. → Forgey Foundry
Logical role: Shared watcher runtime
Canonical source candidate: D:\THE SPARK\FOUR\03_Forgey_Foundry\01_Engines\03_Master_Engine
Weight status: Proposed 14% of Forgey Foundry; remains provisional pending Foundry rebalancing after InstaDater becomes top-level.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Build one production-grade shared watcher runtime that safely runs isolated profiles, enforces authorization and permissions, maintains truthful lifecycle state, produces reconstructable evidence, recovers safely, and integrates with Control, Router, InstaDater, and Desktop without duplicating them.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

The complete approved runtime is implemented, secured, tested, documented, independently packaged, installable/updateable/repairable/rollback-capable, proven across approved profile types and devices, accepted for production, and safely cut over from legacy behavior.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- Master Engine is one shared watcher runtime, not Forgey Control, Router, InstaDater, Desktop, or a profile.
- One canonical engine codebase serves isolated independently identified profiles.
- Runtime truth comes from current process and heartbeat evidence, never fixtures or stale PID files.
- Forgey Local remains unchanged until accepted replacement cutover.
- Master Engine v1.0.0 remains unreleased.
- Forgey Global is the first primary replacement-profile proof; Pet Forge remains an application.
- Bare minimum requires two generated isolated profiles and safe rollback without premature legacy replacement.
- Q55 asked for the total roadmap phases. The accepted roadmap uses 12 phases.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

One canonical engine securely runs two generated isolated fixture profiles, validates authorization, enforces roots/actions, supervises lifecycle, produces evidence, recovers safely, and rolls back without replacing Forgey Local.

Comfortably Functional / Purple:

Reliable daily operation across several profiles/devices with mature diagnostics, compatibility, performance, upgrades, recovery, Control/Desktop integration, and low-friction evidence review.

First Green work target / pause point:

Approve goal, boundaries, source inputs, source-reconciliation plan, profile-contract direction, and acceptance evidence before runtime source modification.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==========================

PET FORGE 🐢
PROTO v1.0.0 ROADMAP
Version: 1.0
Date: 2026-07-13
File type: Stable planning roadmap (.txt)

======================================================================
PURPOSE
======================================================================

This roadmap defines the approved development sequence for Pet Forge.

Pet Forge is a Windows-first desktop computer-pets app built around:
- Three launch pets
- Smooth modern 2D presentation
- Advanced desktop pet physics
- Optional Ollama-powered conversation and reactions
- Optional visual awareness and continuous screen watch
- Local, editable memory and learning
- Multi-monitor support
- Strong privacy, performance, backup, and recovery controls

This file is a stable roadmap, not a live-status file.
Current progress, test results, blockers, and active work should remain in chat,
memory, reports, or a separate approved live-status system.

======================================================================
SOURCE-OF-TRUTH RULES
======================================================================

1. Proto v1.0.0 is one complete prototype target delivered through internal
   staged gates.

2. The first executable remains intentionally small and safe.

3. Inspect before editing, always.

4. Planning approval does not authorize coding, execution, installation,
   deletion, deployment, purchases, destructive changes, screen capture,
   microphone access, camera access, cloud transmission, or computer control.

5. Coding remains unauthorized until:
   - UX planning is approved
   - Technical architecture is approved
   - Drive folder and source-of-truth plan is approved
   - Risks and rollback plans are approved
   - Acceptance tests are approved
   - Explicit coding authorization is given

6. Blank answers in approved Pet Forge questionnaires mean the related
   Workbench recommendation is accepted.

7. PASS, HOLD, PARTIAL, or FAIL decisions must be evidence-based.

======================================================================
APPROVED PRODUCT BASELINE
======================================================================

Working name:
Pet Forge

Initial platform:
Windows

Future architecture:
Should not block later macOS or Linux versions.

Initial visual style:
Smooth modern 2D

Later visual direction:
3D pets and advanced dynamic lighting

Launch pets:
1. Original ground character
2. Forgey — original hovering AI companion, user-renamable
3. Robot pet

Primary product balance:
Mostly entertainment with optional productivity abilities

Core AI models:
- qwen3:4b
  Purpose: pet conversation, personality responses, reaction selection,
  and behavior decisions

- qwen2.5vl:7b
  Purpose: screenshots, selected regions, visual understanding,
  visual awareness, and optional continuous screen watch

Development-only model:
- qwen2.5-coder:7b and/or qwen2.5-coder:14b
  Purpose: development and diagnostics only
  Not a runtime pet brain

Excluded runtime model:
- gpt-oss:20b

Deep-conversation mode:
Not included

======================================================================
DRIVE AND WORKSPACE RULES
======================================================================

Use both:
1. The organized D: drive structure
2. The approved Drive/controller workflow

Inspect before every edit.

Approved Pet Forge local data path for Doonchy's computer:
D:\03_Other_Apps\02_Data\01_Pet_Forge

Use organized numbered folders.

Separate:
- Source
- Planning
- UX
- Architecture
- Prompts
- Reports
- Evidence
- Pet assets
- AI configuration
- Runtime data
- Memory
- Visual history
- Backups
- Exports
- Logs
- Releases
- Archives

Do not mix live status into stable roadmap, template, or structure files.

======================================================================
PROTO v1.0.0 GATE MAP 🐢
======================================================================

Proto v1.0.0 is delivered through the following internal gates:

Gate 0  — Pre-Implementation Controls
Gat

F.O.U.R. PORTFOLIO WEIGHTS AND PROGRESS RULES ROADMAP — REVISION
Roadmap version: 0.1.1
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Supersedes: v0.1.0 parent-allocation assumption only
Implementation authority: NONE

Current The Spark parent allocation:

- F.O.U.R.: 90%
- InstaDater: 10%
- Total: 100%

The Spark progress formula:

The Spark Blue Current =
  (0.90 × accepted F.O.U.R. Blue Current)
+ (0.10 × accepted InstaDater Blue Current)

Equivalent formulas apply to accepted Amber, Purple, and Green markers, unless
a separately approved hard gate caps the parent.

Important:

- Forgey AIO remains a F.O.U.R. family.
- InstaDater is not counted in the Forgey Foundry child-weight total.
- Foundry child weights must be rebalanced to exactly 100% after removing the
  prior internal InstaDater allocation.
- Until that table is approved, Foundry child weights are provisional even
  where individual questionnaires accepted proposed values.
- No Blue Current changes merely because this revision exists.

FORGEY FOUNDRY — ROY COMPUTER INSTALLATION ROADMAP
Version: 1.0.0
Date: 2026-07-21
Status: APPROVED PLANNING SOURCE
Parent: The Spark → F.O.U.R. → Device Installations → Roy Computer
Component type: Device-specific installation, migration, and cutover roadmap
Proposed parent allocation: No parent component weight; report device-install progress separately
Numerical Blue Current rule: Display three separate numbers: Legacy Forgey Local/GCB operational baseline 85% provisional; F.O.U.R./Foundry system readiness for a controlled Roy test 18% provisional; Roy accepted new-architecture installation progress 0% until installation evidence exists.
Implementation authority: SEPARATE EXPLICIT OWNER AUTHORIZATION

==============================================================================
NORTH STAR
==============================================================================

Complete the safe Roy-specific Foundry installation supporting approved projects and AI work while preserving the working legacy setup until replacement proof and rollback are accepted.

Plain-language purpose:
The exact Forgey setup Roy needs without breaking what already works.

Explicitly not:
A generic all-components install, permission to access all family data, or proof that the new architecture is already installed.

==============================================================================
100% COMPLETION
==============================================================================

Roy's approved installation, F.O.U.R. Desktop lifecycle authority, InstaDater transactions, Forgey Desktop, Forgey:7b, Router/Control visibility, approved runtime/profile, project workflows, recovery, support, cutover, and observation are fully proven and Owner/Roy accepted.

Plans, folders, elapsed time, questionnaires, and roadmap connections do not
increase Blue Current. Progress changes require accepted evidence against this
weighted roadmap.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:
- Infrastructure plus one safe project/profile workflow without replacing legacy.
- Verified Desktop/InstaDater lifecycle.
- Scoped local AI and recovery.

Comfortably Functional / Purple:
- Reliable daily Roy workflows.
- Approved new runtime/profile.
- Remote visibility/control.
- Local AI, updates, recovery, and minimal support.

First Green work target / pause point:
- Approve Roy's target install matrix and produce a no-change preflight.
- Pause for Owner and portfolio review before continuing.

==============================================================================
WEIGHTED PHASES
==============================================================================

PHASE 01 — Roy hardware, role, paths, legacy baseline, and backup
Weight: 12%
ETUC: 55–95 active hours

Deliverables:
- Inspect Roy hardware, Windows/account context, project roots, Drive lanes, Forgey Local/GCB baseline, model configuration, and backups.

Evidence gate:
- Hardware and path report passes.
- Legacy 85% operational baseline is documented separately.
- Rollback backup is verified.

Stop / return condition:
- HOLD if hardware, paths, or working legacy behavior cannot be reconstructed.
PHASE 02 — Roy target install matrix and no-change preflight
Weight: 12%
ETUC: 45–80 active hours

Deliverables:
- Define Roy workflows, required packages, permissions, storage, exclusions, dependency order, and coming-soon placeholders.

Evidence gate:
- Owner/Roy review passes.
- Preflight makes no changes.
- No unsupported component is included.

Stop / return condition:
- Return if install scope or role permissions remain unclear.
PHASE 03 — Bootstrap, Resend verification, InstaDater, and F.O.U.R. Desktop
Weight: 14%
ETUC: 65–110 active hours

Deliverables:
- Verify Roy account email through Resend.
- Install InstaDater.
- Install F.O.U.R. Desktop.
- Enable Desktop

SHARED SCHEMAS ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: F.O.U.R. → Forgey Foundry
Logical role: Cross-component schema, validation, and compatibility system
Canonical source candidate: D:\THE SPARK\FOUR\03_Forgey_Foundry\01_Engines\04_Shared_Schemas
Weight status: Proposed 8% of Forgey Foundry; provisional pending parent rebalancing.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Give every Foundry component one versioned, language-neutral, validated meaning for identity, manifests, inventory, authorization, commands, runtime state, evidence, errors, packages, and compatibility.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

All approved cross-component contracts are authoritative, versioned, semantically documented, validated, canonicalized, migratable, code-generatable where approved, proven across consumers/producers, secured, released, and Owner-accepted.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- JSON Schema is the initial authoritative language-neutral source.
- Generated typed bindings are derived, not independent truth.
- Security-sensitive unknown fields are rejected; namespaced extensions require explicit design.
- Breaking changes require a new major version and migration/compatibility evidence.
- Canonical deterministic serialization is required for hashes, signatures, idempotency, and evidence.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

Core identity, manifest, inventory, status, authorization, command, receipt, evidence, error, package, and compatibility contracts work in fixture integrations.

Comfortably Functional / Purple:

Released components upgrade safely across supported schema versions with mature migrations, diagnostics, generated bindings, and predictable deprecation.

First Green work target / pause point:

Freeze identity, manifest, runtime-status, and authorization-envelope schemas for fixtures, then pause.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==============================================================================

01. Contract inventory and source reconciliation            10%   25–45h
02. Authority, identity, and naming rules                   10%   25–45h
03. Core schema set                                         22%   60–105h
04. Validation and canonical serialization                  15%   45–80h
05. Compatibility, migrations, and deprecation              15%   45–85h
06. Generated bindings                                      10%   35–70h
07. Cross-component integration proof                       10%   40–75h
08. Rel

WATCHER PROFILE SDK / GENERATOR ROADMAP
Roadmap version: 0.1.0
Date: 2026-07-21
Status: DRAFT FOR OWNER APPROVAL
Parent: F.O.U.R. → Forgey Foundry
Logical role: Watcher-profile generation, validation, packaging, and lifecycle toolkit
Canonical source candidate: Canonical path unresolved under D:\THE SPARK\FOUR\03_Forgey_Foundry
Weight status: Proposed 7% of Forgey Foundry; provisional pending parent rebalancing.
Implementation authority: NONE

==============================================================================
NORTH STAR
==============================================================================

Provide one safe supported system for defining, generating, validating, testing, packaging, installing, updating, repairing, and rolling back isolated profiles that run on the shared Master Engine.

==============================================================================
100% COMPLETION DEFINITION
==============================================================================

Approved users can create reliable least-privilege profiles with complete manifests, tests, fixtures, packages, documentation, compatibility, lifecycle metadata, automatic inventory registration, and Owner-accepted release evidence.

==============================================================================
LOCKED OWNER DECISIONS
==============================================================================

- Doonchy remains final Owner authority.
- The canonical F.O.U.R. hierarchy and component boundaries remain evidence-controlled.
- Source, runtime, fixtures, packages, releases, evidence, backups, and archives remain distinguishable.
- Dangerous actions require fresh authorization.
- Failure and uncertainty produce truthful HOLD, PARTIAL, or FAIL states.
- Backup, rollback, negative testing, and evidence are mandatory.
- Roadmap progress is weighted and evidence-backed.
- The questionnaire and roadmap do not authorize implementation.
- Use one deterministic CLI/core library first; a Forgey Desktop wizard later reuses the same validator.
- Profiles may contain custom code only when isolated, reviewed, dependency-locked, capability-scoped, and tested.
- Valid installation automatically creates persistent inventory and appears Installed/Stopped before first run.
- v1 proof uses Forgey Global fixture plus a least-privilege second fixture profile.

==============================================================================
FUNCTIONAL MARKERS
==============================================================================

Bare Minimum / Amber:

Generate two distinct fixture profiles that install, register, remain isolated, run safely in fixtures, and roll back.

Comfortably Functional / Purple:

Routine profile creation through CLI and a shared-core Desktop wizard with strong diagnostics, migrations, documentation, multi-device packages, and reliable recovery.

First Green work target / pause point:

Generate and validate a Forgey Global fixture and minimal second profile without live execution, then pause.

Blue Current rule:

Blue Current changes only when this roadmap is Owner-approved and accepted
evidence proves completion of weighted capabilities. Plans, questionnaires,
folders, elapsed time, imports, and roadmap creation do not increase Blue.

==============================================================================
WEIGHTED PHASE SUMMARY
==============================================================================

01. Goal, source, and profile-contract lock                 10%   25–45h
02. Templates and deterministic core                        12%   40–75h
03. Validator and diagnostics                               15%   45–80h
04. Capability, permission, and isolation model             15%   50–90h
05. Fixtures and test harness                               10%   35–65h
06. Packaging and profile artifacts                         10%   35–65h
07. Top-level InstaDater integration                        10%   40–75h
08. Multi