Home Mac app guides

Mac app guides

Mac app guides for Firestruct modules, Firebase project linking, emulator and production targets, Firestore queries, Auth user management, Storage browsing, task monitoring, PITR recovery, push testing, seed data, migrations, workspace links, purchases, and support. Use these articles when working in the native macOS workspace and reviewing UI safety labels.
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. Start Here - Foundation and App Shell: workspace layout, 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, CRUD, imports, exports, transfers, backups, and schema tools. - Auth: user search, filtering, editing, custom claims, bulk actions, import/export/transfer, scripts, and Auth-to-Firestore linking. - Storage: bucket browsing, upload/download/delete, URL actions, thumbnails, and profile photo integration. - Push: FCM payload validation, token resolution, and send results. - PITR Recovery: current vs historical Firestore document diff and guarded restore. - Index Advisor: missing-index explanation, index comparison, and remediation helpers. - Seed Studio: deterministic fixture generation, snapshots, and drift comparison. - 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 deploy flows. - Support: in-app Chatwoot support. - Purchases and Pro Access: entitlement model and gated actions. Every module also has a cli.md page. CLI support currently covers project selection, module selection, Firestore query/create/update/delete commands, and broad Auth administration including list/search/create/update/delete, bulk enable/disable, import/export/transfer, and local Auth scripts. 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 Firebase Admin context, 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 May 07, 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. - 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. 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 May 07, 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 mutation workspace. It covers simple queries, JavaScript queries, table/tree/json/log output, document and collection CRUD, schema analysis, import/export, transfer, backups, and context actions. 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 Supported operators: < <= == > >= != array-contains array-contains-any in not-in starts-with starts-with is a prefix-search abstraction. Firestore index errors surface with creation links and Index Advisor context where available. JS Query JS Query runs local JavaScript with an async run() entrypoint and Firebase Admin context. It supports Firestore reads, writes, deletes, batches, count aggregation, structured returns, logs, and utility packages exposed by the bundled runtime. 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 Users can: - 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, overwrite warning, operation semantics, and same-project path validation. 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 - 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 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 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. 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 May 07, 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 admin.auth() support. Scripts can list users, update users, return structured objects for table/tree/json rendering, and emit logs. Auth to Firestore Linking Project settings can define a Firestore user document mapping, defaulting to Auth uid to Firestore document ID. Auth user views can open linked Firestore user documents and show clear linked/unlinked states. Storage Photo Workflow When Storage is configured, the Auth editor supports profile photo upload. The app uploads the file to Storage, writes the resulting URL back to photoURL, shows thumbnails, and offers preview/copy/open URL actions. 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 May 07, 2026

Storage GUI

Purpose The Storage module browses and manages Firebase Storage buckets for emulator and production targets. It also supports Auth profile photo upload and thumbnail workflows. 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. 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 - upload files - download files - delete files - copy URL - generate signed URL with configurable expiration - open URL - show thumbnail preview when an object is image-compatible - integrate profile photo upload from Auth Emulator and Production Storage uses the selected project and Storage emulator endpoint when configured. Production object mutations must be explicit and visible. 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 and object path. - Long uploads/downloads/deletes should report progress through Tasks where applicable. 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 May 07, 2026

Push GUI

Purpose The Push module helps validate and send Firebase Cloud Messaging payloads. It resolves target tokens from configured sources, supports script-based token selection, and records send results. Outputs - TABLE: token/source/result rows - JSON: raw payload, resolved token data, and service responses - LOGS: validation, resolver, API, and 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. Send with explicit confirmation. 7. Review per-token results 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. - Failed sends should expose actionable per-token errors. 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 May 07, 2026

PITR Recovery GUI

Purpose PITR Recovery lets users load a current Firestore document and a historical point-in-time version, inspect the diff, and restore the historical version with guardrails. Flow 1. Select a project and Firestore database. 2. Enter a document path. 3. Enter a whole-minute recovery timestamp. 4. Load current and historical versions. 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 and historical document JSON - LOGS: REST read/write, validation, and task logs Validation - Document path is required. - Recovery timestamp must be valid and whole-minute aligned. - Restore requires that a historical version was loaded successfully. Use the module for incident response 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 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 confirmation. - Restore should run through the task queue. - The diff should make changed, added, removed, and unchanged fields clear before confirmation. 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 May 07, 2026

Index Advisor GUI

Purpose Index Advisor explains Firestore query-index failures and compares a query shape against known project indexes. Deterministic checks are mandatory; AI explanations are optional overlay content. Inputs Index Advisor works from: - current Firestore query shape - captured query/index errors - synced project 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: sync, parse, compare, warning, and error logs Actions Users can: - sync or refresh current project indexes - inspect why a query requires an index - compare filters/order clauses to current indexes - open/create a required index - copy an index spec - verify again after index creation - 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, current index set, missing fields, and Firebase error text so users can verify why a recommendation was produced. Use AI-assisted wording only as an optional overlay. The core result must remain reproducible from synced indexes and the query shape, which is what makes the module safe for production troubleshooting and support handoff. Safety - Index sync and diagnosis are read-oriented. - 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 May 07, 2026

Seed Studio GUI

Purpose Seed Studio generates deterministic Firestore seed data from schemas/templates, stores seed snapshots, and compares generated snapshots with current project 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 Firestore with confirmation. 7. Later, compare original snapshot values against current project data for drift. Outputs - TABLE: generated records, snapshot rows, or drift rows - JSON: seed template, generated payloads, snapshots, and drift details - LOGS: generation, validation, 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 project. Safety - Seed apply is a Firestore write and is Pro-gated. - Template file persistence is Pro-gated. - Production seed apply requires explicit confirmation. - Apply operations should be task-backed and expose overwrite behavior. 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 May 07, 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, and environment alignment before execution workflows are enabled or applied. 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 and source file content. Execution hooks are phase 2 and must be guarded by production confirmation, read-only checks, Pro access, and task queue progress. 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 escalating to an execution path outside Firestruct. 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 - Applying migrations is Pro-gated. - Production migration apply requires explicit confirmation. - Migration execution must run through Tasks. - Source file content and remote records should be visible before apply. 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/FirestructCore/FirewayIntegrationService.swift - Sources/FirestructCore/ProjectRegistry+Migrations.swift

Last updated on May 07, 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 run guarded deploy 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 - deploy selected configuration 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. Safety - Workspace link persistence is Pro-gated. - Deploy is Pro-gated and requires explicit confirmation. - Production deploys must label target project/environment clearly. - Deploy operations must run through Tasks and expose errors. 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 May 07, 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. Safety Pro access does not bypass project read-only mode or production confirmation. Entitlement, read-only, and confirmation checks are separate guardrails. 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 May 07, 2026