# Command Dashboard Inventory Phase

Use this when starting a multi-domain command dashboard over existing sensitive systems (finance, health, media automation, agent/system ops) and the user asks for an inventory/review rather than new functionality.

## Pre-implementation discipline

Before writing files, state a short implementation note:

- change list
- affected files
- test plan
- explicit non-goals / disabled functionality

Then execute only the inventory deliverables. Do not bootstrap apps, adapters, UI, APIs, or runtime services unless the user explicitly advances to the next phase.

## Safe discovery rules

- Inspect repository code, README files, schemas without data, package manifests, route definitions, start scripts, and docs.
- Do not open/copy productive SQLite DBs, CSV/XLSX exports, PDFs, generated reports, OAuth files, tokens, Drive-link JSONs, or runtime logs that may contain sensitive values.
- It is acceptable to document productive paths as paths, but not to read or commit their contents.
- For GitHub tokens, verify access behaviorally via one-shot credential helpers; never print token contents/hashes.

## Required inventory outputs

For each domain system capture:

- start commands
- ports and URLs
- existing APIs / route inventory
- existing dashboards and whether they are user/admin/fallback
- productive runtime paths
- sensitive data areas
- backup/restore mechanisms
- suitable integration points
- No-Go areas

For a cross-system candidate file, classify every integration with a traffic light:

- **Green** — immediately read-only integrable.
- **Yellow** — only through sanitizing/adapter/allowlist.
- **Red** — not for the global dashboard or not for MVP.

Every recommendation must include a short reason, not just a label.

## FinanceManager patterns

For FinanceManager-style systems, prioritize these read-only candidates first:

- `GET /api/health` for module liveness.
- `GET /api/provider/status` for sanitized provider readiness.
- `GET /api/runtime/status` only after redacting local DB paths; expose booleans such as runtime outside repo and DB available.
- `GET /api/system/status` only with log/path details removed; no restart actions in MVP.
- amount-free import/review audit endpoints for counts.
- command-center endpoints only via explicit allowlist; never pass through raw wealth, cash, position, merchant, account, report path, or file data to the global overview.

Treat all POST/confirm/delete/archive/restart/generate/update endpoints as disabled until there is a separate command-dashboard contract plus Preview -> Confirm -> Audit and gateway audit.

## HealthManager patterns

For HealthManager-style systems without an HTTP API, start with a cautious adapter or status API. Suitable global data is limited to sanitized summaries:

- pipeline/runtime availability
- report freshness as existence/mtime only
- encrypted backup freshness/status
- open review counts only as numbers
- document/status counts only after stripping names, paths, institutions, Drive IDs/URLs, and content

Never show globally:

- full lab values or trend details
- PDF text / extracted medical contents
- Drive links / file IDs / local original paths
- symptoms, diary, nutrition text, medication details, doctor/institution names
- raw Apple Health or YAZIO values
- generated report contents or direct report-file downloads

Pipeline commands that generate reports, register inbox files, upload to Drive, or mutate DB state are red for MVP.

## MVP start page constraints

For this user's JARVIS Command Dashboard class of work, enforce:

- iPad UX is mandatory.
- Max 5 attention items.
- Max 4 module cards.
- Max 3 KPIs per card.
- No tables or raw data on the start page.
- Legacy dashboards are links only unless a later technical/security note justifies embedding.

## Verification checklist

After writing inventory docs:

- Run a secret/sensitive pattern scan over the new docs.
- Verify no forbidden file types were added: `.db`, `.sqlite*`, `.csv`, `.xlsx`, `.pdf`, `.gpg`, `.env`, OAuth/credential files.
- Check file existence and non-trivial size.
- Review git diff/stat before commit.
- If pushing, verify remote branch SHA after push.

## Report format after phase

Return:

- changed files
- architecture decisions
- tests / real command results
- UI screenshot or explicit statement that no UI was created
- risks/open points
- what remains intentionally disabled
- concrete priority list for next implementation phase