Home Mac app guides

Mac app guides

Use the Mac app guides to learn Firestruct through its native macOS workspace. Start with Firebase project linking, authentication, emulator endpoints, workspace tabs, and the task monitor, then move into practical Firestore querying, document editing, tree and JSON views, column controls, and guarded production mutations. The guides also cover Firebase Authentication user administration, Cloud Storage browsing and transfers, imports and exports, index advice, deterministic seed generation, point-in-time recovery workflows, push notification testing, Fireway migration visibility, and local Firebase workspace links. Every guide distinguishes emulator-safe development from production operations and calls out confirmation prompts, validation rules, overwrite behavior, progress reporting, retries, and current feature boundaries. Use this category when you are working in the Firestruct app and need the exact UI path, expected result, or safety requirement for a Firebase operation.
By Tomas Radvansky
15 articles

Start here

Firestruct is a native Firebase workspace for macOS. It connects to Firebase projects and emulators, lets users inspect and manage Firestore/Auth/Storage data, and adds guarded workflows for tasks such as imports, exports, transfers, push testing, seeding, migrations, and point-in-time recovery. Implementation completion is evidence-based: Firebase behavior must be proven with emulator runs or approved live Firebase verification. Mock-only proof is not enough for user-facing workflows. Start Here - Foundation and App Shell: workspace layout, collapsible sidebar trees, tabs, split view, output modes, feature flags, and command palette. - Project Registry: linking projects, selecting environments, emulator setup, read-only mode, and local project state. - Firestore: queries, JS scripts, table/tree/json/log views, emulator-proven CRUD/import/export/transfer/backups, live request-shape guardrails, and schema tools. - Auth: user search, filtering, editing, custom claims, bulk actions, import/export/transfer, scripts, and Auth-to-Firestore linking. - Storage: emulator-proven bucket browsing, upload/download/delete, folder and multi-selection workflows, ZIP and URL actions, thumbnails, guarded production controls, and Auth photo URL handoff. - Push: FCM payload validation, token resolution, simulated sends, and guarded send attempts. - PITR Recovery: point-in-time request shape, current vs historical diff output, and guarded restore prep while live proof remains open. - Index Advisor: deterministic query/index comparison, local index checks, and captured backend-link parsing while live missing-index UI proof remains open. - Seed Studio: deterministic fixture generation, emulator seed snapshots, and drift comparison against current emulator data. - Tasks: queue, progress, counters, errors, and retry visibility for long-running work. - Migrations: Fireway file and Firestore migration status inspection. - Workspace Link: local Firebase workspace link, rules/index viewing, diffing, and guarded deploy prep. - Support: in-app Chatwoot support. - Purchases and Pro Access: entitlement model and gated actions. Operator and maintainer references: - Verification Contract: required emulator, live-project, PR, and release-candidate evidence. - Live Verification Template: evidence format for approved live Firebase runs. - Open Verification Backlog: remaining live, StoreKit, UI-runner, and release proof that must not be marked complete from mocks or request-shape tests. Every module also has a cli.md page. CLI support includes project/module and Firestore-database selection; Firestore querying, backups, import/export/transfer, scripts, embeddings, schema, and writes; Auth administration, per-project tenant discovery/selection, and Auth-to-Firestore route management/resolution; Storage object/folder/bulk workflows; Tasks history; Index Advisor; Seed Studio; Workspace Link; PITR; Push; Migrations; and release-evidence preflight. Basic Concepts Project: a local link to a Firebase or emulator target. Firestruct stores display name, Firebase project ID, environment, read-only status, emulator endpoints, selected Firestore database, color tag, and module settings. Environment: the target type: emulator, development, or production. Production mutations and deploys require explicit confirmation. Module: a workspace area such as Firestore, Auth, Storage, Tasks, or Index Advisor. GUI modules open in tabs and may expose output modes. Output mode: a result view such as TABLE, TREE, JSON, LOGS, or Storage BROWSER. Task: a queued long-running operation with status, progress, counters, duration, errors, and retry controls. Read-only project: a project guardrail that blocks writes and destructive actions. Pro-gated action: a paid capability such as writes, deletes, imports, exports, uploads, deploys, scripts, transfers, and saved local workflows. Simple query: a Firestore query built from path, filters, ordering, and limit. JS Query / script: a local JavaScript run() workflow with Firestruct's Admin SDK-style local shim, structured results, and captured logs. Workspace link: a local Firebase repo association using files such as firebase.json and .firebaserc. Safety Defaults - Show target project and environment before every mutation. - Require explicit confirmation for production writes, destructive operations, deploys, seed applies, migration applies, and push sends. - Validate same-project move and rename paths before running. - Make overwrite behavior visible before confirmation. - Run long imports, exports, transfers, deploys, seeds, migrations, and recursive mutations through Tasks. - Keep credentials and Firebase data local to the user's machine.

Last updated on Jul 14, 2026

Foundation and App Shell GUI

Purpose The app shell gives every module a consistent workspace: project selection, module navigation, tab management, split panes, output mode switching, feature flags, command palette actions, settings, and persisted session state. Entry Points - The sidebar shows the Firestruct brand, linked projects, visible modules, and task queue status. - Auth, Firestore, and Storage module rows open the module and toggle their nested sidebar trees. Expanding a row loads its tenants, databases/collections, or buckets; collapsing it hides the tree without changing the active module. - Sidebar database, root-collection, Auth-tenant, and Storage-bucket entries use localized alphabetical ordering. - Modules open inside workspace tabs. Most modules support opening another tab and split view when more than one tab exists. - The command palette opens quick module and action navigation. - Settings and Support are workspace modules rather than standalone windows. Sidebar Trees - Auth shows project-wide Auth plus discovered or configured tenants. - Firestore shows databases and the selected database's root collections. Its context menu can refresh databases or open the add-database sheet. - Storage shows available buckets. - Module context menus expose refresh and new-tab actions where supported. - Selecting a nested tenant, database, collection, or bucket updates the corresponding module state before opening that module. Workspace Tabs - Each tab has a module, title, selected output mode, and tab ID. - Tabs can be opened from module actions, project context actions, collection/document actions, and cross-module links. - The active tab controls the visible module surface. - Split view shows another workspace tab beside the current one. - The tab strip appears when multiple pane tabs exist or split view is enabled. - Closing a tab is allowed when more than one tab exists. Output Modes The app shell renders a segmented output picker when the active module exposes output modes. | Module | Output modes | | --- | --- | | Firestore | TABLE, TREE, JSON, LOGS | | Auth | TABLE, TREE, JSON, LOGS | | Storage | BROWSER, JSON, LOGS | | Push | TABLE, JSON, LOGS | | PITR Recovery | TABLE, JSON, LOGS | | Index Advisor | TABLE, TREE, JSON, LOGS | | Seed Studio | TABLE, JSON, LOGS | | Migrations | TABLE, JSON, LOGS | The shell normalizes unsupported output modes back to the module default. Feature Flags Feature flags control visible modules and experimental behavior. Tests enable all module flags. Runtime flags can come from app configuration or FIRESTRUCT_FEATURE_* environment variables. Key flags: - FIRESTRUCT_FEATURE_FIRESTORE - FIRESTRUCT_FEATURE_AUTH - FIRESTRUCT_FEATURE_STORAGE - FIRESTRUCT_FEATURE_PUSH - FIRESTRUCT_FEATURE_PITR - FIRESTRUCT_FEATURE_INDEX_ADVISOR - FIRESTRUCT_FEATURE_SEED_STUDIO - FIRESTRUCT_FEATURE_VECTOR_SEARCH - FIRESTRUCT_FEATURE_TASKS - FIRESTRUCT_FEATURE_MIGRATIONS - FIRESTRUCT_FEATURE_BYPASS_PRO_ACCESS State Restoration The shell restores linked projects, selected project, tabs, split view state, saved Firestore/Auth module state, selected output modes, and local workspace settings from local stores. Safety and Access - The shell displays the selected target project and environment in module headers. - Read-only and Pro gates are enforced before module actions perform mutations or save paid workflows. - Destructive and long-running actions are delegated to module-specific services and the task queue. Source Anchors - Sources/FirestructApp/App/FirestructApp.swift - Sources/FirestructApp/App/UI/SidebarView.swift - Sources/FirestructApp/App/UI/ModuleTabView.swift - Sources/FirestructApp/App/Services/SessionStateStore.swift - Sources/FirestructApp/Shared/Models/WorkspaceModels.swift

Last updated on Jul 12, 2026

Project Registry GUI

Purpose Project Registry stores every Firebase target Firestruct can operate on. The GUI uses it for project linking, selection, emulator configuration, account metadata, read-only mode, color tags, Firestore database selection, and module-specific configuration. Project Linking Users can link projects through the project sheet from the sidebar. Supported project sources: - Google OAuth account discovery - Service Account JSON - Firebase CLI credentials detected on the machine - Local emulator manual setup - Local emulator discovery after app startup Stored project fields include: - display name - Firebase project ID - environment (emulator, development, production) - read-only flag - emulator host and ports for Firestore/Auth/Storage - selected Firestore database ID - project color tag - optional local workspace path - module-specific settings such as Auth user collection mapping, push token mapping, and migration collection Sidebar Behavior - The selected project row is highlighted. - Rows show name, Firebase project ID, selected Firestore database, environment, emulator endpoint when present, and read-only status. - The project color tag helps distinguish multiple connected projects. - Removing a linked project only removes local metadata; it does not delete Firebase data. Multiple Firestore Databases The registry can discover, persist, select, and refresh Firestore database IDs for a linked project. Module queries and writes use the selected database. Safety - Read-only projects block writes and destructive workflows across modules. - Environment is shown in module headers and mutation dialogs. - Production targets require explicit confirmation for mutations and deploys. Source Anchors - Sources/FirestructCore/ProjectRegistry.swift - Sources/FirestructCore/ProjectRegistry+Stores.swift - Sources/FirestructCore/ProjectRegistry+WorkspaceServices.swift - Sources/FirestructCore/ProjectRegistry+Migrations.swift - Sources/FirestructCore/SQLiteProjectStore.swift - Sources/FirestructCore/FirestoreDatabaseDiscoveryService.swift - Sources/FirestructApp/App/UI/ProjectLinkSheetView.swift - Sources/FirestructApp/App/UI/SidebarView.swift

Last updated on May 07, 2026

Firestore GUI

Purpose The Firestore module is the primary data exploration and guarded mutation workspace. It covers simple queries, JavaScript queries, table/tree/json/log output, emulator-proven document and collection CRUD/import/export/transfer/backups, live request-shape guardrails, schema analysis, and context actions. Current status note: emulator-backed query, CRUD, import/export, transfer, table editing, column split/unsplit, table context/pasteboard/range selection, tree traversal/subcollection CRUD, direct tree context-menu create/delete, and lifecycle overwrite permutations have focused emulator proof. Phase 1 still tracks backend missing-index link rendering as partial because parser/app affordance tests exist, but real backend missing-index reproduction and UI proof require an approved live Firebase project. Phase 2 live single-document write work has service-level REST request-shape proof plus GUI/AppModel target labels, production confirmation guards, task queueing, and missing-credential task failure evidence; approved disposable live read-back/cleanup proof remains open. Live import now has JSON/CSV REST request-shape, preview, typed-confirmation, task-counter, missing-credential, and invalid-source guard evidence, but approved disposable live import read-back/cleanup remains open. Live export has GUI/AppModel source-scope preview and Pro-gate proof plus CLI request-shape/task/artifact evidence under stubbed live transport; approved disposable live export and cleanup remain open. Query Modes Simple Query The simple query builder supports: - collection, subcollection, and document paths - collection group queries - multiple where clauses - multiple orderBy clauses - nested-field autocomplete - document reference values in filters - explicit limit, including zero for all documents - query validation before execution - saved queries - vector nearest-neighbor query mode when the vector search flag is enabled - local embedding provider configuration persistence and GUI/CLI management - GUI and CLI custom HTTP embedding generation for emulator collections through the task queue Supported operators: < <= == > >= != array-contains array-contains-any in not-in starts-with starts-with is a prefix-search abstraction. Firestore index error parsing and UI affordances exist, and the Firestore module can send the current Simple query shape to Index Advisor without waiting for a backend error. Local embedding provider configuration is persisted per project as validated metadata only, and GUI plus CLI embedding-config set/show/delete management is available. The Vector GUI and CLI can run a custom HTTP embedding batch against Firestore emulator collections: they read the current/requested collection path, POST { "model": "...", "inputs": [...] } to the configured endpoint, write the returned numeric embedding arrays to the configured field through Firestore REST arrayValue, and report progress through Tasks. Native Firestore vector-value writes, OpenAI/Vertex execution, Firebase-proven vector ranking, and live Firestore embedding writes remain planned. Real backend missing-index link proof remains pending until an approved live Firebase run is completed. JS Query JS Query runs local JavaScript with an async run() entrypoint and Firestruct's Admin SDK-style local shim. It supports Firestore reads, local runtime writes/deletes/batches, emulator write-through when explicitly confirmed, count aggregation, structured returns, logs, and utility packages exposed by the bundled runtime. Live JavaScript write-through remains open until approved live Firebase verification exists. Output Modes - TABLE: editable grid, column controls, inline values, selections, context actions - TREE: hierarchical document/collection navigation, including remembered subcollections - JSON: read-only structured result view - LOGS: transport, app, warning, error, and script logs Table and Column Controls Target behavior: - show, hide, search, and reorder columns - drag columns in the columns panel - toggle system columns such as Doc ID, createTime, updateTime, and readTime - split nested map fields into columns and unsplit them - persist column configuration in saved tab/query state - quick-filter visible rows - copy/paste cells - use keyboard navigation - multi-select rows with shift-click - copy field values and field names from context menus Data Editing Document workflows: - create document - edit fields inline - edit whole document as JSON - duplicate document - copy document - move document - rename document ID - delete document - reveal/open current collection or document in Firebase Console Collection workflows: - create collection - rename collection through recursive copy and cleanup - duplicate/copy/move collections across projects - delete collections - include nested subcollections in recursive copy/move/rename flows Bulk field workflows: - add a field with a constant value to a collection/query/selection - rename a field across documents - delete a field across documents Move, rename, duplicate, and copy dialogs show source project/path, target project/path, source and target database/environment labels, overwrite warning, recursive subcollection behavior, estimated root count, operation semantics, and same-project path validation. Production source or target transfer plans require typing TRANSFER <source-project-id> TO <target-project-id> before queueing can proceed. Live transfer tasks resolve source and target credentials independently; approved disposable live execution and cleanup evidence remains required before production transfer parity is claimed. Import, Export, Transfer, Backup Export supports: - JSON - newline-delimited JSON - CSV - archive backups - query-result exports - path-scoped exports - document ID and resource path inclusion - subcollection inclusion - pre-export preview - source-scope summary with project, environment, database, path/query, limit, subcollection mode, and destination - optional reveal in file manager Import supports: - JSON array/object roots - Firefoo special type syntax such as __time__, __lat__, __lon__, __ref__, bytes, and double markers - CSV type mapping - column normalization - root-level import from absolute document path column - Latin1 files - JSON, CSV, and archive file selection - target project and target path validation - target project/environment/database/path, overwrite mode, document count, and sample-row preview logs - typed live import confirmation before any live-target enqueue attempt - JSON and CSV live REST request-shape support with task progress; approved live read-back and cleanup remain required before completion is claimed Transfer supports: - project-to-project and project-to-emulator transfers - selected collections - include/exclude subcollections - optional target clean first - document reference transformation - saved transfer definitions - context-driven direct copy/move across projects - copy-before-delete move semantics with separate copy/delete logs Large imports, exports, backups, recursive mutations, and transfers run through Tasks. Schema and Inspection Tools The schema analyzer can inspect collection structure and generate: - tree schema - TypeScript - Dart - Kotlin - Java - Swift - Objective-C - JSON Schema Tree tools include expand all, collapse all, and CSV export. Result views include generated header metadata. Visualization support includes GeoPoint maps, latitude/longitude field maps, and image URL previews. Safety - Read-only projects block Firestore writes and destructive actions. - Pro access gates writes, deletes, imports, exports, transfers, saved queries/scripts, and script execution. - Production mutations require confirmation. - Overwrite and delete behavior is never hidden. - Firestore production write/import/transfer support is not broadly complete yet. Single-document create/update/delete can queue for live targets through the task engine after Pro/read-only/production-confirmation checks, but approved disposable live verification is still required before live success is claimed. Source Anchors - Sources/FirestructApp/Features/Firestore/UI/FirestoreModuleView.swift - Sources/FirestructApp/Features/Firestore/UI/FirestoreModuleView+QueryControls.swift - Sources/FirestructApp/Features/Firestore/UI/FirestoreModuleView+Controls.swift - Sources/FirestructApp/Features/Firestore/UI/FirestoreModuleView+ImportExportControls.swift - Sources/FirestructApp/Features/Firestore/UI/FirestoreModuleView+Outputs.swift - Sources/FirestructApp/Features/Firestore/Services/ - Sources/FirestructCore/FirestoreSimpleQueryService.swift - Sources/FirestructCore/FirestoreDocumentWriteService.swift - Sources/FirestructCore/FirestoreSchemaAnalyzerService.swift - Sources/FirestructCore/JavaScriptQueryService.swift

Last updated on Jul 12, 2026

Auth GUI

Purpose The Auth module manages Firebase Authentication users. It supports user listing, search, sorting, filtering, editing, bulk actions, import/export, transfers, JS scripting, provider visibility, custom claims, and Auth-to-Firestore linking. User List and Search The table/grid supports: - paginated or streaming user list loading - sorting by email, phone, UID, created time, and last login - direct search by UID, email, and phone number - local filtering by display name, claim value, provider, email verified, disabled/enabled status, creation range, and last sign-in range - combined filters - saved search presets - real-time result updates Output Modes - TABLE: user grid and primary admin workflow - TREE: structured user/provider/claim view - JSON: raw user payload view - LOGS: Auth API, app, script, warning, and error logs User Editing Editable or visible fields: - UID - created timestamp, read-only - last login timestamp, read-only - email - password update flow - hashed password import/update path where supported - phone number - display name - photo URL - disabled state - email verified state - custom claims/tokens - provider linkage visibility - linked provider list User actions: - create user, including custom UID - edit attributes - delete user - disable or enable user - mark or unmark email verified - bulk disable - bulk delete Import, Export, Transfer The module supports CSV/JSON import and export plus project-to-project transfer of users. Long-running imports, exports, deletes, disables, and transfers should run through Tasks. JS Scripting Auth JS scripts run locally with a local admin.auth()-style shim. Scripts can list users, update the local runtime snapshot, return structured objects for table/tree/json rendering, and emit logs. Use the Auth editor/import/transfer actions for Firebase mutations. Auth to Firestore Linking Auth/Firestore linking settings belong to the project selected in the sidebar. The Auth source dropdown selects project-wide Auth, a discovered/configured tenant, or a custom tenant ID when discovery is unavailable. The Firestore destination dropdown selects a linked Firestore instance and database as one endpoint; collection path is configured separately. This lets multiple tenants share one Firestore instance with separate collections or route to different Firestore instances without presenting a generic Firebase-project selector. UID mapping can use the Firestore document ID or a field value; shared collections can additionally filter by a tenant discriminator field/value pair. Auth user views can open linked Firestore user documents and show clear linked/unlinked states. Current emulator evidence covers persisted mapping settings, selected-project sync, linked and missing Auth-side states, disabled navigation for a missing Firestore document, Auth-to-Firestore navigation, and focused Firestore-to-Auth reverse navigation. App-state tests cover selected-project route ownership, endpoint selector state, tenant-scoped route selection, shared-collection discriminator filtering, cross-project/database forward routing, and reverse restoration of the source Auth project and tenant. The endpoint-selector XCUITest passed on 2026-07-12 against external Firebase emulators and created one tenant route to a separate Firestore destination plus another route to a nested collection in the selected project's Firestore instance. Its retained result bundle is build/emulator-ui-artifacts/20260712-150333-auth-firestore-endpoint-selectors.xcresult. Storage Photo Workflow When Storage is configured, the Auth editor can write a selected Storage download URL back to photoURL. Current emulator proof covers the Storage URL handoff path: choosing an existing Storage object URL, writing it through the Auth editor, verifying the Auth emulator value, and confirming the Storage object remains browsable. Direct file-picker upload proof and approved live Storage proof remain open. Signed URL generation is handled separately by the Storage URL action. Safety - Read-only projects block Auth writes. - Pro access gates Auth mutations, import/export, transfer, and scripts. - Production writes and destructive actions require confirmation. Source Anchors - Sources/FirestructApp/Features/Auth/UI/AuthModuleView.swift - Sources/FirestructApp/Features/Auth/UI/AuthModuleView+Controls.swift - Sources/FirestructApp/Features/Auth/UI/AuthModuleView+Editor.swift - Sources/FirestructApp/Features/Auth/UI/AuthModuleView+Outputs.swift - Sources/FirestructApp/Features/Auth/Services/ - Sources/FirestructCore/AuthListService.swift - Sources/FirestructCore/AuthListService+Operations.swift

Last updated on Jul 12, 2026

Storage GUI

Purpose The Storage module browses and manages Firebase Storage buckets with emulator-proven workflows and guarded production controls. It also supports Auth photo URL handoff and thumbnail workflows; direct Auth file-picker upload proof remains open. Browser Output The BROWSER output mode is the primary file navigation surface. Users can browse folders/files, switch between list and grid layouts, sort entries by name, size, or updated date, inspect metadata, preview supported files, and run object actions. Selecting one or more objects reveals a toolbar with the selection count, an actions menu, and a clear-selection control. Additional output modes: - JSON: raw listing/action payloads - LOGS: Storage API and app logs Actions Supported workflows: - browse bucket paths - sort by name, size, or updated date - switch between list and grid views - create folders and upload files by picker or drag and drop - upload files - download files - delete files - rename, duplicate, copy, move, and delete folders - download selected objects individually or as a ZIP archive - copy selected download URLs - copy, move, or delete selected objects in bulk - copy URL - generate signed URL with configurable expiration - open URL - show thumbnail preview when an object is image-compatible - integrate Auth photo URL handoff from Storage Emulator and Production Storage uses the selected project and Storage emulator endpoint when configured. Production object mutations must be explicit and visible, but approved live bucket verification remains open. Production signed URLs use linked service account JSON credentials for V4 signing; emulator links generate local emulator download URLs with the selected expiration for deterministic UI coverage. Safety - Read-only projects block uploads and deletes. - Pro access gates Storage writes. - Destructive deletes show the target project/environment, bucket, and object path. - Production single-object and bulk-object deletes require DELETE PRODUCTION before queueing. - Production folder deletes require DELETE FOLDER PRODUCTION before queueing. - Long uploads/downloads/deletes should report progress through Tasks where applicable. Current Verification - Storage emulator UI coverage proves browser, sort/grid, visible selection controls, details, preview, signed URL, upload, download, delete, folder, ZIP, and bulk object workflows against seeded emulator objects. - Storage CLI emulator coverage proves upload/download/delete, browser output, ZIP payloads, folder copy/move, task retention, and read-only mutation rejection. - StorageProductionDeleteGuardTests/testProductionObjectDeleteRequiresProductionConfirmationBeforeQueueingTask, testProductionBulkDeleteRequiresProductionConfirmationBeforeQueueingTask, and testProductionFolderDeleteRequiresFolderProductionConfirmationBeforeQueueingTask prove production deletes require typed production confirmation before task enqueue. - Approved live bucket list/upload/signed-URL/download/delete cleanup proof remains open. Source Anchors - Sources/FirestructApp/Features/Storage/UI/StorageModuleView.swift - Sources/FirestructApp/Features/Storage/Services/AppModel+StorageActions.swift - Sources/FirestructApp/Features/Storage/Model/StorageStore.swift - Sources/FirestructCore/StorageService.swift

Last updated on Jul 12, 2026

Push GUI

Purpose The Push module helps validate Firebase Cloud Messaging payloads, resolve target tokens from configured sources, and run clearly labeled simulated or guarded send attempts. Real FCM delivery remains unclaimed until approved live project/device evidence exists. Outputs - TABLE: token/source/result rows - JSON: raw payload, resolved token data, validation output, simulated results, and guarded send responses - LOGS: validation, resolver, API, simulated-send, and guarded-send logs Token Sources Push token sources can come from project-level configuration such as Firestore token paths, Auth/Firestore user mappings, saved token lists, or scripts. Script templates help users build repeatable token resolution workflows. Use named token sources for repeatable QA and support workflows. A saved source should explain where tokens come from, which project setting owns the path or script, and how stale or invalid tokens will be reported after a send attempt. Send Flow A typical flow: 1. Select the target project. 2. Configure or choose a token source. 3. Enter notification/data payload fields. 4. Validate the payload. 5. Resolve tokens. 6. Run a clearly labeled simulated send or a guarded send attempt with explicit confirmation. 7. Review per-token simulated results, guarded-attempt errors where available, and logs. Keep payload review separate from delivery. Validate notification fields, data keys, token count, and environment before pressing send, especially when the selected project is production or the token source comes from linked Auth and Firestore records. Safety - Push send is Pro-gated. - Production sends require explicit confirmation. - Token scripts are Pro-gated and should be treated like local code execution. - Simulated sends must stay visibly labeled and cannot count as real delivery evidence. - Failed guarded send attempts should expose actionable per-token errors. Current Verification - Payload validation, token-source resolution, no-credential dry-run simulation, live-send credential enforcement, per-target HTTP response capture, read-only rejection, and production confirmation are covered by service and CLI tests. - Real FCM delivery remains open until an approved live project/device fixture records API responses and cleanup or token invalidation notes. Source Anchors - Sources/FirestructApp/Features/Push/UI/PushModuleView.swift - Sources/FirestructApp/Features/Push/Services/AppModel+PushActions.swift - Sources/FirestructApp/Features/Push/Services/AppModel+PushTokenSourcePersistence.swift - Sources/FirestructCore/PushTestingService.swift - Sources/FirestructCore/PushTokenSourceResolverService.swift - Sources/FirestructCore/PushTokenScriptTemplates.swift

Last updated on Jul 12, 2026

PITR Recovery GUI

Purpose PITR Recovery helps users prepare point-in-time document load requests, inspect available current-vs-recovered diff output, and prepare guarded restore workflows. Approved live PITR-enabled Firebase proof remains required before live historical reads or restores are treated as complete. Flow 1. Select a project and Firestore database. 2. Enter a document path. 3. Enter a whole-minute recovery timestamp. 4. Build current and historical read requests; use approved live evidence before treating historical results as production-proven. 5. Review field diff, JSON, and logs. 6. Restore the historical document version only after explicit confirmation. Outputs - TABLE: field-level diff and recovery summary - JSON: current document JSON, recovered/stubbed payloads when available, and request details - LOGS: REST read/write, validation, and task logs Validation - Document path is required. - Recovery timestamp must be valid RFC 3339, whole-minute aligned with seconds set to 00, not in the future, and inside the configured recovery window. - Restore requires an available recovered snapshot from approved live evidence or a fixture-backed/stubbed recovery payload. Current local validation evidence covers timestamp parsing, whole-minute rejection, future-time rejection, and configurable recovery-window bounds. Local recovery guard evidence covers recovered-field PATCH construction, read-only rejection before task enqueue, missing-recovered-document rejection, and production typed confirmation before task enqueue. Historical reads and restores still require approved live PITR-enabled Firebase verification before they should be treated as production-proven. Use the module for incident response prep when a single Firestore document needs careful review before restoration. The operator should select the Firebase project, Firestore database, document path, and historical timestamp, then compare the current data against the recovered snapshot when an approved live or fixture-backed snapshot is available before approving any write. That keeps recovery evidence visible instead of hiding it inside an external script. The table and JSON outputs are useful for different review styles. Table output summarizes changed fields, missing fields, and restored values, while JSON output keeps the raw document payload available for copying into a ticket or runbook. Logs should capture request timing, selected target details, PITR API errors, and restore validation failures. Safety - Restore is a Firestore write and is blocked for read-only projects. - Production restore requires explicit RECOVER <project-id> confirmation. - Restore should run through the task queue. - The diff should make changed, added, removed, and unchanged fields clear before confirmation. Current Verification - FirestorePITRServiceTests/testValidateReadTimeAcceptsWholeMinuteWithinRecoveryWindow, testValidateReadTimeRejectsNonWholeMinuteTimestamps, testValidateReadTimeRejectsFutureAndOlderThanSevenDays, and testValidateReadTimeUsesConfiguredRecoveryWindow prove timestamp guardrails. - FirestorePITRServiceTests/testRecoverDocumentPatchesRecoveredFieldsWithLiveAuthorization proves the recovery PATCH body uses recovered fields, with stubbed transport only. - PITRRecoveryGuardTests/testReadOnlyProjectRejectsPITRRecoveryBeforeQueueingTask, testProductionPITRRecoveryRequiresTypedConfirmationBeforeQueueingTask, and testMissingRecoveredDocumentRejectsPITRRecoveryBeforeQueueingTask prove app-level recovery guardrails before task enqueue. - Approved live PITR-enabled Firebase proof remains required before live historical read or restore behavior is claimed. Source Anchors - Sources/FirestructApp/Features/PITR/UI/PITRRecoveryView.swift - Sources/FirestructApp/Features/PITR/Services/AppModel+PITRActions.swift - Sources/FirestructApp/Features/PITR/Model/PITRStore.swift - Sources/FirestructCore/FirestorePITRService.swift

Last updated on Jul 12, 2026

Index Advisor GUI

Purpose Index Advisor deterministically compares a Firestore query shape against loaded local or workspace index definitions and can parse captured query-index failure text. Deterministic checks are mandatory; AI explanations are optional overlay content. Inputs Index Advisor works from: - current Firestore query shape - captured query/index errors - loaded local or workspace index definitions - manually entered query/index data Outputs - TABLE: query clauses, required fields, and index comparison rows - TREE: structured query shape and index coverage explanation - JSON: raw index specs, parsed error data, and diagnostics - LOGS: load, parse, compare, warning, and error logs Actions Users can: - send the current Firestore Simple query shape from the Firestore module - load local or workspace index definitions when available - inspect why a query requires an index - compare filters/order clauses to loaded index definitions - open a captured backend index-creation URL when available - copy an index spec - verify again after index definitions change - review proactive warnings for likely composite-index requirements Index Advisor should make the deterministic evidence visible before any explanation. Show the query path, filters, order clauses, loaded index set, missing fields, and Firebase error text so users can verify why a recommendation was produced. Current-query handoff does not require a backend missing-index error: the Firestore module can send its active Simple query path, filters, and ordering to Index Advisor for deterministic analysis against the currently loaded index JSON. Backend missing-index errors can still enrich the handoff with creation URLs and raw Firebase error details when available. Matching is deterministic and order-sensitive. An existing composite index is not treated as covering a query merely because it contains the same fields; the required field sequence must match the index prefix and orderBy directions must match. Extra trailing fields may still be present after the required prefix. Use AI-assisted wording only as an optional overlay. The core result must remain reproducible from loaded index definitions and the query shape, which is what makes the module safe for production troubleshooting and support handoff. Safety - Index loading and diagnosis are read-oriented; live remote sync remains open until approved backend evidence exists. - Index creation/deploy-style workflows are Pro-gated or routed through Workspace Link when they mutate project configuration. - Explanations should preserve raw deterministic evidence so users can verify the recommendation. Source Anchors - Sources/FirestructApp/Features/IndexAdvisor/UI/IndexAdvisorView.swift - Sources/FirestructApp/Features/IndexAdvisor/Services/AppModel+IndexAdvisorActions.swift - Sources/FirestructApp/Features/IndexAdvisor/Model/IndexAdvisorStore.swift - Sources/FirestructCore/IndexAdvisorService.swift - Sources/FirestructCore/FirestoreIndexCreationLinkSummary.swift

Last updated on Jul 12, 2026

Seed Studio GUI

Purpose Seed Studio generates deterministic Firestore seed data from schemas/templates, stores seed snapshots, and compares generated snapshots with current emulator data for drift. Flow 1. Select target project/database. 2. Define or choose a schema/template. 3. Configure deterministic seed options. 4. Generate preview data. 5. Review snapshot output and logs. 6. Apply the seed to a Firestore emulator with confirmation. 7. Later, compare original snapshot values against current emulator data for drift. Outputs - TABLE: generated records, snapshot rows, or drift rows - JSON: seed template, generated payloads, snapshots, and drift details - LOGS: generation, validation, emulator apply, and readback logs Snapshot and Drift Seed snapshots record generated values so teams can compare original fixture data with current Firestore documents. Drift output should identify unchanged, changed, missing, and extra fields/documents where the service can classify them. Use snapshots as review evidence, not just generated fixtures. A snapshot should make the target collection paths, deterministic seed options, generated document IDs, and expected field values visible before any apply operation begins. Drift comparison is useful after manual testing or shared emulator sessions. It helps identify which records still match the seed, which were edited during the test, and which expected documents are missing from the current emulator target. Current app-test evidence covers the schema-editor and preview state used by the GUI. The editor can compose generated fields, structured nested maps, static template values, document ID templates, and count, then apply through the task queue to a real Firestore emulator and read the generated documents back. Changing the deterministic seed changes the generated snapshot digest and document rows, and returning to the same seed restores the same preview. Apply Snapshot and Apply Partial now share an explicit overwrite toggle; document ID templates no longer infer overwrite automatically, and project switching clears the overwrite choice with the live-write confirmation. Reset + Reapply remains an emulator-only action that always logs overwrite and reset intent. CLI integration coverage also proves emulator-backed apply, partial apply, and drift. Live seed apply remains open. Safety - Seed apply is a Firestore write and is Pro-gated. - Template file persistence is Pro-gated. - Production seed apply requires explicit confirmation. - Emulator apply operations are task-backed and expose overwrite/reset behavior before enqueue. - Live seed apply remains unclaimed until approved live verification proves disposable writes and cleanup. Source Anchors - Sources/FirestructApp/Features/SeedStudio/UI/SeedStudioView.swift - Sources/FirestructApp/Features/SeedStudio/Services/AppModel+SeedStudioActions.swift - Sources/FirestructApp/Features/SeedStudio/Services/AppModel+SeedStudioPersistenceAndGeneration.swift - Sources/FirestructCore/SeedStudioService.swift - Sources/FirestructCore/SeedStudioService+GenerationUtilities.swift

Last updated on Jul 12, 2026

Tasks GUI

Purpose Tasks is the shared monitor for long-running and risky operations. It gives users visibility into queued, running, successful, and failed operations without blocking core UI work. Covered Operations Required task-backed flows include: - delete - move - copy - import - export - transfer - deploy - seed - migration runs - large uploads/downloads where progress matters - PITR load/restore where task state is needed Task State Each task should expose: - status: queued, running, success, failed - progress - operation counters - duration - retry action when supported - error details with actionable messages - logs or details sufficient for troubleshooting UI Behavior The task queue appears in the workspace/sidebar and opens the Tasks module for detailed inspection. Users should be able to monitor work while navigating other modules. Use Tasks as the audit trail for work that is risky, slow, or easy to lose track of during normal navigation. A user should be able to start an import, move to Firestore or Auth, and still see whether the queued operation is waiting, running, complete, failed, or ready for retry. Task details should make failures actionable. Include the operation name, target project, environment, affected path or resource, completed and failed counters, elapsed duration, and the original error message. When a task represents a destructive or production action, the detail view should make that target context impossible to miss. Safety Task visibility does not replace confirmation dialogs. Destructive or production operations still require explicit confirmation before a task is enqueued. Source Anchors - Sources/FirestructApp/Features/Tasks/UI/TaskMonitorView.swift - Sources/FirestructApp/Features/Tasks/Services/AppModel+TaskActions.swift - Sources/FirestructApp/Features/Tasks/Model/TaskStore.swift - Sources/FirestructCore/TaskOrchestrator.swift

Last updated on May 07, 2026

Migrations GUI

Purpose The Migrations module integrates local Fireway migration files with Firestore migration records. It helps users inspect migration status, source contents, record pending migrations as applied when an external migration runner has already executed them, execute pending migration source against Firebase emulators, and verify environment alignment before any execution workflow is used. Inputs - linked local workspace path - Fireway migration files - configured migration collection - selected project/database - Firestore migration records Outputs - TABLE: migration status rows - JSON: raw migration records and file metadata - LOGS: local file, Firestore, parse, and comparison logs Actions Current GUI coverage includes listing status, source file content, a record-only "Record Pending As Applied" workflow, and an emulator-only "Execute Pending (Emulator)" workflow. The record-only action writes migration records for pending local files through the task queue; it does not execute Fireway source code. GUI source execution is emulator-only. It runs pending Fireway-compatible JavaScript through the task queue, applies emitted Firestore mutations to the selected Firestore emulator, records migration state, refreshes status rows, and keeps rollback notes/logs visible. Production/live execution must not be claimed until approved live verification proves the workflow and guardrails. Use this module when a release or support session needs to answer four questions before running any migration tooling: which local files exist, which Firestore migration records exist, which files appear unapplied, and which project/database is being inspected. Keeping those details in one view reduces the risk of comparing local development files against the wrong Firebase environment. The source preview is intentionally part of the workflow. Review the migration body, file name, identifier, and remote record together before recording a pending file as applied or using the emulator execution path. If a record is missing or mismatched, use the logs output to determine whether the issue came from local file discovery, workspace-link configuration, Firestore access, or migration collection setup. Safety - Recording migrations as applied is Pro-gated. - Read-only projects reject record-applied state writes before any task is queued. - Production record-applied state writes require explicit confirmation. - Record-applied state writes run through Tasks and surface task logs/progress. - Migration source execution is GUI-available for emulator projects only. - Non-emulator source execution rejects before task enqueue. - Source file content and remote records should be visible before recording state or using the emulator execution path. Current Verification - MigrationWorkflowCopyTests/testMigrationWorkflowCopyDistinguishesInspectRecordAndExecute proves the GUI-facing labels distinguish status inspection, record-only state writes, emulator-only source execution, and live execution boundaries. - MigrationWorkflowCopyTests/testProductionRecordAppliedGuardUsesRecordOnlyWording proves production confirmation rejection uses record-applied state-write wording and does not queue logs before confirmation. - MigrationWorkflowCopyTests/testProductionRecordAppliedPromptNamesStateWriteNotExecution proves the production prompt says the action does not execute migration source. - MigrationWorkflowCopyTests/testReadOnlyRecordAppliedRejectsBeforeQueueingTask proves read-only GUI record-applied requests stop before task enqueue. - MigrationWorkflowCopyTests/testGUIRecordAppliedWritesPendingMigrationRecordThroughTaskQueueAgainstEmulator proves the GUI/AppModel record-applied action queues a task against real Firebase emulators, writes the migration record, refreshes applied status, records rollback notes/logs, and reads back the emulator document. - MigrationWorkflowCopyTests/testGUIExecutePendingMigrationSourceWritesEmulatorMutationAndRecord proves the GUI/AppModel source-execution action queues a task against real Firebase emulators, runs Fireway-compatible JavaScript, applies the emitted Firestore mutation, records migration state, refreshes applied status, and reads back both the script-written emulator document and migration record. - MigrationWorkflowCopyTests/testNonEmulatorMigrationExecuteRejectsBeforeQueueingTask proves GUI source execution rejects non-emulator projects before task enqueue. - FirestructCLIIntegrationTests/testCLICommandsRoundTripAgainstFirebaseEmulators proves emulator-backed migration status, record-applied record-only writes, and emulator-only JS apply execution with Firestore mutation and migration-record read-back evidence. Source Anchors - Sources/FirestructApp/Features/Migrations/UI/MigrationExplorerView.swift - Sources/FirestructApp/Features/Migrations/Services/AppModel+MigrationActions.swift - Sources/FirestructApp/Features/Migrations/Model/MigrationStore.swift - Sources/FirestructApp/Features/Migrations/Model/MigrationWorkflowCopy.swift - Sources/FirestructCore/FirewayIntegrationService.swift - Sources/FirestructCore/ProjectRegistry+Migrations.swift

Last updated on Jul 12, 2026

Workspace Link GUI

Purpose Workspace Link associates a Firestruct project with a local Firebase workspace. It lets users view local project configuration, inspect rules/index files, diff local vs remote state, and prepare guarded deploy prep/dry-run command-shape workflows. Inputs - local workspace path - firebase.json - .firebaserc - Firestore rules and indexes - Storage rules where configured - selected Firebase project Actions Users can: - link a local workspace path - inspect workspace files - view rules/index contents - compare local configuration against remote project state - prepare task-backed deploy dry-run/real-deploy command shapes with explicit confirmation when enabled The module is useful before any rules or indexes change because it keeps local files, Firebase aliases, selected project metadata, and remote state in the same review surface. A user should be able to see which checkout is linked, which Firebase project will be affected, and what differs before deciding whether a deploy is appropriate. Diff views should favor deterministic output over interpretation. Show the local file path, remote resource, changed sections, missing files, parse errors, and any Firebase API errors separately so a developer can fix local config or permissions without guessing which layer failed. Current diff cards surface a machine-readable reason label and diagnostics for local missing files, remote missing state, content changes, malformed firestore.indexes JSON, and remote credential/API failures. Firebase Rules and Firestore Indexes REST failures should name the service, HTTP status, backend message, and access-token/IAM remediation hint. Safety - Workspace link persistence is Pro-gated. - Deploy is Pro-gated. - Real deploys reject read-only projects before queueing work. - Production real deploys require explicit typed confirmation. - Production deploys must label target project/environment clearly. - Deploy operations must run through Tasks and expose errors. Current Verification - WorkspaceLinkRemoteServiceTests/testWorkspaceConfigDiffServiceClassifiesMissingAndParseStates covers deterministic diff reasons for remote-missing, local-missing, both-missing, and parse-error states. - WorkspaceLinkRemoteServiceTests/testFetchDeployedConfigSurfacesActionableCredentialAndAPIErrors covers actionable Firebase Rules and Firestore Indexes REST failure logs. - FirestructCLIIntegrationTests/testWorkspaceLinkCLIInspectsAndDiffsLocalFirebaseWorkspace covers local workspace link/status/diff output against a real temporary Firebase workspace and explicit comparison files. - WorkspaceDeployTaskTests/testWorkspaceDryRunDeployQueuesTaskAndCapturesCLIOutput covers the macOS dry-run deploy task path, task counters, command shape, and captured output through a deterministic command runner. - WorkspaceDeployTaskTests/testWorkspaceDryRunDeployFailureCapturesCommandAndFirebaseOutput covers failed dry-run task output, preserving the exact Firebase CLI command, stdout JSON, stderr text, and zero processed operations in app errors/logs. - WorkspaceDeployTaskTests/testWorkspaceRealDeployRequiresProAccessBeforeQueueingTask, testWorkspaceRealDeployRejectsReadOnlyProjectBeforeQueueingTask, and testWorkspaceProductionRealDeployRequiresTypedConfirmationBeforeQueueingTask cover real deploy guardrails before task enqueue or CLI execution. - A local 2026-06-26 real Firebase CLI dry-run attempt against demo-firestruct reached Firebase and returned project-not-found JSON; this validates failure-output capture but is not successful dry-run proof. Real successful Firebase CLI dry-run output against a valid local workspace/project and approved live deploy proof remain open before deploy completion can be claimed. Source Anchors - Sources/FirestructApp/Features/WorkspaceLink/UI/WorkspaceLinkView.swift - Sources/FirestructApp/Features/WorkspaceLink/Services/AppModel+WorkspaceLinkActions.swift - Sources/FirestructApp/Features/WorkspaceLink/Model/WorkspaceLinkStore.swift - Sources/FirestructCore/WorkspaceLinkRemoteService.swift - Sources/FirestructCore/WorkspaceLinkRemoteService+Operations.swift - Sources/FirestructCore/ProjectRegistry+WorkspaceServices.swift

Last updated on Jul 12, 2026

Support GUI

Purpose Support embeds Firestruct help and Chatwoot support access inside the app so users can ask for help without leaving their workspace context. Behavior - Support is a visible workspace module. - It does not support output modes or workspace tabs in the same way data modules do. - The support panel uses Chatwoot configuration and web view/controller components. The support surface is meant for product help, setup questions, and issue handoff when a Firestruct workflow needs human review. It should keep users in context: the selected module, project type, environment, and recent logs are the details most likely to make a support request actionable. Users should still avoid pasting secrets into support conversations. Service account JSON, OAuth tokens, Firebase access tokens, private user data, and production exports should stay local unless a secure support process explicitly requests a redacted artifact. For routine questions, link to the relevant help article first and include screenshots or logs only when they clarify the issue. Help-Center Relationship The docs in this folder are intended to become source content for help.firestruct.com. Support articles should be imported from module gui.md and cli.md files when the help center is ready. Help-center articles should use stable module names, clear safety language, and links that resolve to published article slugs rather than repository paths. That keeps search crawlers and users away from broken Markdown source URLs. Source Anchors - Sources/FirestructApp/Features/Support/UI/SupportModuleView.swift - Sources/FirestructApp/Features/Support/UI/ChatwootSupportWebView.swift - Sources/FirestructApp/Features/Support/UI/SupportWidgetPanelController.swift - Sources/FirestructApp/Features/Support/Model/ChatwootSupportConfiguration.swift

Last updated on May 07, 2026

Purchases and Pro Access GUI

Purpose Purchases and Pro Access enforce Firestruct's commercial access model. Free users can connect projects, inspect read-only data, use Settings, and use Support. Pro access unlocks write, destructive, export/import, upload, deploy, script, and saved-workflow capabilities. Entitlements The app supports: - Pro monthly - Pro yearly - lifetime purchase - restore purchase Gated Capabilities Current Pro feature gates include: - Auth import/export - Auth writes - Auth scripts - Firestore export - Firestore import - Firestore writes - saved Firestore queries - saved Firestore scripts - Firestore scripts - Firestore transfer - Index Advisor sync - migration apply - Push send - Push token scripts - seed apply - seed template files - Storage writes - Workspace deploy - Workspace link persistence Paywall Behavior When a gated action is requested without entitlement, the app should present the paywall before work begins. The paywall must not enqueue tasks or mutate local/external state until purchase or restore succeeds. The paywall should name the requested capability so users understand why it appeared. For example, exporting Auth users, applying a seed, uploading Storage objects, or running a Firestore script should each connect the purchase prompt to the action the user selected. Restore purchase must be easy to find and should update entitlement state before the blocked action resumes. If restore fails, the app should leave the original operation unstarted and show an actionable StoreKit or network error. Current local verification covers the app-state boundary: successful purchase service completion activates Pro access and closes the paywall, restore activates Pro access when an active entitlement is returned, restore with no active entitlement keeps the paywall open with a clear status message, and failed purchase keeps the original gated operation unstarted. This is not StoreKit transaction proof; a local StoreKit test-plan run or approved sandbox purchase run is still required before claiming purchase/restore execution through StoreKit itself. Safety Pro access does not bypass project read-only mode or production confirmation. Entitlement, read-only, and confirmation checks are separate guardrails. Verification - swift test --filter StoreKitReleaseWiringTests passed on 2026-06-26 with 9 tests. - Remaining release gate: run a real StoreKit local configuration or sandbox flow that records purchase success and restore success or actionable restore failure through StoreKit itself. Source Anchors - Sources/FirestructApp/Features/Purchases/Model/ProAccessState.swift - Sources/FirestructApp/Features/Purchases/Services/AppModel+Purchases.swift - Sources/FirestructApp/Features/Purchases/Services/StoreKitPurchaseService.swift - Sources/FirestructApp/Features/Purchases/UI/PaywallView.swift

Last updated on Jul 12, 2026