FORGE MOBILE — COMMAND

Shared memory

Records owned by SHARED. Choose the acting role — FORGE CORE enforces that role's permissions on every call, including direct function calls, not just in this UI.

Audit log

Append-only through the UI: creates, edits, deletions, permission denials, owner confirmations, imports and exports are recorded. This log is not tamper-proof — anyone who can edit this file or the browser's storage can alter it. It is an accountability aid, not proof.

Export backup (JSON)

Export is an owner operation covering all owners (JB, MARI, SHARED) and is audit-logged.

Import backup (JSON)

The entire file is validated before anything is written. If any record is invalid, the whole import is aborted and nothing is imported. Valid imports are written in a single IndexedDB transaction covering both the memories and the audit entry, so a failed write rolls back instead of leaving a partial import. Fallback caveat: if this device is running in localStorage fallback mode (see the banner), imports are not crash-atomic — that store writes two keys sequentially and a crash between them can leave it inconsistent.

Permissions enforced by FORGE CORE

Threat model — honest boundaries

FORGE CORE's permission checks are real code: every create, read, edit, delete, import and export in this app goes through them, and calling the underlying functions directly with the wrong role fails the same way (the test suite does exactly that). But browser JavaScript cannot defend against: malicious or modified code running in this same page/origin, browser extensions with page access, a compromised or rooted phone, someone with your unlocked phone, or you (the owner) editing this file. "Owner confirmation" in this app is a consent prompt, NOT authentication: any code in this page can pass the confirmation flag, and cross-role access for JB/MARI is therefore blocked structurally (no role function accepts it at all) rather than by the flag. There is no encryption at rest in v0.1 — anyone who can read the browser profile or an export file can read the memories. The audit log is not tamper-proof. Treat this as a personal, single-device integrity tool, not as a security boundary against an attacker who controls the device.

Automated tests

Tests run against a separate throwaway database and never touch your real memories. They call FORGE CORE functions directly — including with the wrong role on purpose — so a pass means the permission code refused, not that a button was hidden.

Superbrain coordinator

Staged pipeline: FORGE CORE classifies the task (a deterministic heuristic — CORE is not an LLM), JB and MARI analyse independently in parallel through their own runtimes (and therefore through FORGE CORE), each then reviews the other's analysis as untrusted data, and CORE synthesizes a briefing where disagreements and uncertainties stay visible. Bounded: one analysis round, one review round, per-stage timeout. Refused during LOCKDOWN. A brain that is unavailable is shown as a gap, never hidden.

Supervised development

MARI drafts a change proposal as text; JB independently reviews it. The result is a document marked PENDING OWNER APPROVAL. FORGE Mobile cannot write files, run code or deploy — this flow applies nothing, ever. You apply approved changes yourself, outside the app.

Project FORTRESS — control & engineering record

Structure inspired by MIL-STD-498 and hazard analysis inspired by MIL-STD-882E. This is not a military certification and no certification is claimed anywhere in this app.

Core state: —

LOCKDOWN stops every JB/MARI action — direct calls and FCP/1 commands alike. Memories and backups are preserved. Recovery operations that remain available in LOCKDOWN are direct owner operations (never protocol messages): status, backup export from the Backup tab, and the owner-confirmed unlock above. Owner delete is NOT a recovery operation and is also stopped. LOCKDOWN persists across restarts until the owner lifts it, and its transitions are failure-safe: the persistent flag is written before the in-memory state changes.

Agent adapters

Adapters reach FORGE CORE only through the AdapterGateway, which stamps each message with the role bound to the adapter's session — a payload cannot choose or change its identity, and OWNER cannot be an adapter role. This is an enforced cooperative boundary inside the page, not identity authentication against other same-page code. The adapters shipped in this file are mocks: deterministic, offline, no model connected. No live AI capability is claimed, and no provider API keys are stored in this file.

Memory health (owner)

Read-only scan of all memories: duplicate groups and contradiction candidates from a disclosed heuristic (shared subject terms, differing negation or numbers). A candidate is a prompt for your review, not a finding — nothing is merged, changed or deleted by scanning.

Model connection diagnostics

What FORGE can actually observe per brain: adapter, status, and — for live adapters — a real probe. Mock adapters pass as mocks; that says nothing about intelligence.

Intelligence benchmarks

Repeatable tasks with deterministic checkers, run against the currently configured adapters (see BENCHMARKS.md). Scores mean something only with a real model connected; mock scores are a harness baseline. One JB task executes model-written JavaScript in this page — it runs only if you tick the box and confirm.

Connect existing brains (JB Neural Fortress · MARI Neural Core)

FORGE Mobile does not contain your original brains and never overwrites itself. For each brain: (1) optionally import its original project files below — they are stored as data (name, size, SHA-256) for later migration and are never executed; (2) when the brain is running as a service that speaks the FORGE Brain Link protocol (FBL/1, see FORTRESS.md), enter its endpoint and run the connection test. A brain is reported CONNECTED only after a real health/chat exchange succeeds. Names and versions below are the values you declared for your projects; FORGE cannot verify them until a real service answers. The MOCK transport simulates a brain service for testing and is always labelled MOCK.

Requirements traceability (FRT-REQ)

Hazard log (FRT-HAZ)

Security limitations report

What this implementation cannot do, stated plainly:

1. It cannot stop code running in the same page. JB/MARI "agents" here are roles enforced by FORGE CORE for anything that calls the core; a same-origin script, a browser extension, or a modified copy of this file can bypass the core entirely and read IndexedDB directly. LOCKDOWN has the same limit (FRT-HAZ-005).

2. Owner confirmation is not authentication (FRT-REQ-003). There is no PIN, password, or passkey gate in this version; anyone holding the unlocked phone can confirm.

3. No encryption at rest. Browser-profile or export-file access reads everything.

4. The audit log is not tamper-proof (FRT-HAZ-008). It is a convenience record.

5. The localStorage fallback is not crash-atomic (two keys, sequential writes).

6. Replay protection covers the bounded seen-set (default 500 msgIds) plus a +/-5 minute timestamp window; an envelope replayed after its msgId is evicted AND with a fresh timestamp is indistinguishable from a new message — message IDs must be treated as single-use by senders.

7. Fail-closed behaviour covers authorization and validation. It cannot cover the browser, the OS, or the device being compromised.

8. FCP/1 protocol identity is cooperative role validation, NOT authentication. Raw envelopes carry caller-supplied role labels. Adapter sessions bind a role at registration and the gateway stamps it, which stops an adapter acting outside its role through the gateway — but any code in this page can register an adapter or ignore the gateway. OWNER authority is not available over the protocol at all.

9. The shipped JB/MARI adapters are deterministic offline mocks. No language model is connected, no live AI capability exists in this file, and no provider secrets are stored in it.

Design decisions & interfaces

Interface: FORGE CORE (in-page). Role methods createMemory / getMemory / listMemories / updateMemory / deleteMemory (actor = JB|MARI); OWNER operations ownerListMemories / ownerDeleteMemory / exportBackup / importBackup; lifecycle init / enterLockdown / exitLockdown; protocol dispatchCommand(envelope) -> result envelope. All methods are async; all writes are (memory + audit) pairs through the store layer.

Interface: FCP/1 envelope. {msgId, version:"FCP/1", sender, recipient:"CORE", command, ts, correlationId, payload}. Result envelopes mirror it with sender "CORE", command "<command>.result", matching correlationId.

Decision D1: cross-role refusal is structural (checks consult no options), chosen after the v0.1 override bypass failed review. D2: duplicate safety via add() in one transaction rather than check-then-write. D3: msgIds burned before authorization so denied commands cannot be replayed either. D4: LOCKDOWN persisted in store meta so a restart cannot clear it. D5: fallback storage retained for file:// usability, with its atomicity limits labelled instead of hidden.

Acceptance criteria: every FRT-REQ's listed tests pass in the Tests tab; the traceability self-test passes; no requirement is marked verified by inspection alone.