GenDash Folder Migration#

1. Preparation & Freeze#

• 1.1 Create the new project folder at /Users/marc/Xcode/GenDash.
• 1.2 Confirm the destination folder is empty before copying the project.
• 1.3 Close Xcode and any other application that may be watching or editing the project.
• 1.4 Confirm there are no unsaved changes in source files, localization worksheets, or documentation.
• 1.5 Record the current Git branch and working-tree status.
• 1.6 Resolve or document the current Git file-watcher warning before relying on the status check.

2. Copy the Project#

2.1 Complete Copy#

• 2.1.1 Make a complete filesystem copy of the project into /Users/marc/Xcode/GenDash.
• 2.1.2 Preserve the .git directory, hidden files, package directories, symlinks, file permissions, and localization bundles.
• 2.1.3 Preserve the Xcode project, workspace, app source, widget source, resources, entitlements, property lists, documentation, scripts, and localization files.
• 2.1.4 Keep the original project folder unchanged as a rollback copy.

2.2 Copy Verification#

• 2.2.1 Confirm the copied repository contains GenDash.xcodeproj and its workspace.
• 2.2.2 Confirm the copied repository contains both the GenDash app target and GenDashWidget extension target.
• 2.2.3 Confirm the copied repository contains the GenDash Localizations, Images, Appliances, Generators, Manuals, and scratch folders.
• 2.2.4 Confirm the copied repository contains AGENTS.md, .agents, MISSION.md, .gitignore, and the string catalogs.
• 2.2.5 Confirm the copied .git directory identifies the same repository, branch, and remote configuration.
• 2.2.6 Confirm the original project remains unchanged after the copy.

3. Xcode Relocation Validation#

3.1 Project References#

• 3.1.1 Open the copied GenDash.xcodeproj from /Users/marc/Xcode/GenDash.
• 3.1.2 Confirm the project navigator contains no red or missing file references.
• 3.1.3 Confirm the workspace opens normally and uses the copied project.
• 3.1.4 Confirm the shared GenDash and GenDashWidget schemes are available.
• 3.1.5 Confirm the Xcode project, workspace, and schemes contain no stale absolute references to the old folder.

3.2 Build, Signing & Runtime#

• 3.2.1 Confirm the main app target retains its original bundle identifier, signing team, entitlements, and property list settings.
• 3.2.2 Confirm the widget target retains its original bundle identifier, signing team, entitlements, and property list settings.
• 3.2.3 Build the main GenDash target from the new location.
• 3.2.4 Build the GenDashWidget target from the new location.
• 3.2.5 Run the app and confirm the widget and Live Activity integration still function.
• 3.2.6 Confirm moving the source folder has not changed device or simulator app data, Keychain behavior, or CloudKit configuration.
• 3.2.7 Do not export or import localizations as part of the folder move.

4. Project-Internal Absolute Path Audit#

4.1 Path Audit#

• 4.1.1 Search the copied project for references to the old project location.
• 4.1.2 Separate Xcode configuration references from scripts and historical recovery files.
• 4.1.3 Confirm the Xcode project, workspace, schemes, entitlements, and property lists are path-independent.
• 4.1.4 Confirm every approved operational script now locates the repository from its own location or the new project path.
• 4.1.5 Test each retained project script from /Users/marc/Xcode/GenDash.
• 4.1.6 Repeat the audit until no required project workflow depends on the old project location.

5. External Scripts, Aliases & Launchers Audit#

5.1 Inventory#

• 5.1.1 Identify the definition and location of the pushgen command.
• 5.1.2 Check shell aliases, shell functions, startup files, and PATH entries for references to the old Antigravity folder.
• 5.1.3 Check symlinks, launch scripts, Automator actions, Shortcuts, LaunchAgents, scheduled jobs, and other local launchers that may invoke GenDash tools.
• 5.1.4 Inventory repository scripts that use absolute paths or assume the old project location.
• 5.1.5 Classify each script or launcher as active, required, optional, or historical.

5.2 Approved Changes & Validation#

• 5.2.1 Update /Users/marc/Scripts/MacOS/lock_gendash.sh so its GenDash localization and string-catalog paths point to /Users/marc/Xcode/GenDash.
• 5.2.2 Update /Users/marc/Xcode/GenDash/AGENTS.md so its localization workflow and locked-file paths point to the new project location.
• 5.2.3 Update /Users/marc/Xcode/GenDash/.agents/skills/gendash-architecture/SKILL.md so its project file links point to the new project location.

6. Final Sign-Off#

6.1 Sign-Off#

• 6.1.1 Verify the active file-locking aliases resolve to the updated script and no active external configuration still references the old project path.
• 6.1.2 Record the changed files and the rollback method before marking the migration complete.
• 6.1.3 Mark the migration complete only after the original folder is no longer needed as a rollback copy.
• 6.1.4 Remove the original folder only as a separate, explicitly approved cleanup action.

7. MacBook Air Migration (Secondary Computer)#

7.1 Preflight#

• 7.1.1 Confirm the MacBook Air’s current GenDash project location, Git branch, working-tree status, local-only commits, and remotes.
• 7.1.2 Confirm the GenDash and Scripts migration commits are available on their remotes before pulling them to the MacBook Air.
• 7.1.3 Confirm /Users/marc/Xcode/GenDash does not already contain a project and preserve the current Air folder as a rollback copy.

7.2 Repository Relocation#

• 7.2.1 Choose the relocation method: move the complete existing checkout when local-only state exists; use a fresh clone when the checkout is clean and fully synchronized.
• 7.2.2 Create the new folder and relocate or clone GenDash into /Users/marc/Xcode/GenDash, preserving .git when moving the existing checkout.
• 7.2.3 Pull the latest GenDash changes in the new location.
• 7.2.4 Verify the branch, history, remotes, tracked files, and working-tree status.

7.3 Xcode and Script Validation#

• 7.3.1 Open the GenDash project or workspace from the new location and confirm both schemes and references are available.
• 7.3.2 Build the main app and widget once from the new location.
• 7.3.3 Pull or clone the /Users/marc/Scripts repository on the MacBook Air and confirm genl, genu, gens, and genx use the updated locking script.
• 7.3.4 Confirm pushgen remains unchanged because it serves the separate Obsidian/Hugo workflow.
• 7.3.5 Confirm no active workflow on the MacBook Air still depends on the old project path.

7.4 Sign-Off#

• 7.4.1 Keep the original MacBook Air folder until the new setup has passed validation.
• 7.4.2 Remove the original MacBook Air folder only as a separate, explicitly approved cleanup action.

GenDash Site Improvements#

1. Project Direction#

• 1.1 Define the website’s three purposes: explain GenDash clearly and drive App Store downloads; provide a technical reference; and offer a Quick Start Guide.
• 1.2 Analyse whether the site is simple, fast, privacy-focused, and easy to maintain through Obsidian and Hugo. Conclusion: simple for visitors and content editing; static and generally fast; privacy-focused for app data; and maintainable, although the publishing infrastructure is more complex than the website itself.
• 1.3 Analyse whether the existing Hugo publishing workflow and English, French, and Spanish structure should be preserved. Conclusion: preserve the current workflow and language structure; they are clear, working, and the English DEV preview fits naturally within them.

2. Homepage#

• 2.1 Analyse whether the homepage explains GenDash clearly within a few seconds.
  • Finding: Yes. The headline, supporting statement, and dashboard mockup quickly establish that GenDash monitors a generator; the iOS app context arrives later in the third paragraph.
• 2.2 Analyse whether the hero headline and supporting text communicate the main problem GenDash solves.
  • Finding: Yes. The Time-to-Empty question makes the outage problem concrete. “Your generator, monitored.” is memorable, but needs the supporting copy to explain the practical benefit.
• 2.3 Analyse whether the homepage presents the most important product benefits in a concise, scannable way.
  • Finding: Partly. The benefits are strong, but they sit in two long paragraphs rather than a short scannable list or set of feature highlights.
• 2.4 Analyse whether support for gas, propane, diesel, battery generators, Home Assistant, and custom telemetry is explained clearly.
  • Finding: Partly. All of these capabilities are named, but they are compressed into one sentence. Home Assistant and custom telemetry would be easier to understand if separated and briefly explained.
• 2.5 Analyse whether the App Store download is the primary and most visible call to action.
  • Finding: Mostly. The App Store badge is the strongest action in the hero and links directly to the correct listing. It appears after three paragraphs and shares its row with About & Contact, so it could be given slightly more prominence.
• 2.6 Analyse whether the free trial, one-time US$4.99 purchase, and no-subscription model are clear.
  • Finding: Complete. The pricing card now states the 7-day trial, one-time US$4.99 purchase, local-equivalent clarification, and absence of subscriptions, ads, cloud accounts, and data harvesting.
• 2.7 Analyse whether the homepage links users effectively to the User Manual, Quick Start Guide, Privacy Policy, and About & Contact pages.
  • Finding: Partly. All four pages are in the navigation, and About & Contact plus the User Manual are linked in the page body. Quick Start Guide and Privacy Policy have no dedicated homepage links outside the navigation.
• 2.8 Analyse the homepage typography, spacing, colors, imagery, and overall visual hierarchy.
  • Finding: Strong overall. The clean typography, orange accent, generous spacing, and dashboard mockup create a calm, credible product page. The long body copy weakens scanning, and the pricing card is visually quieter than its value proposition deserves.
• 2.9 Analyse the homepage on mobile screens for readability, navigation, image sizing, and tap targets.
  • Finding: At a 390 px-wide iPhone viewport, there is no horizontal overflow; the mockup scales to 298 px and the App Store link remains available. The navigation collapses to a hamburger control, but its visible icon is only 18 × 18 px and should be made easier to tap.

3. Quick Start Guide#

• 3.1 Analyse and simplify the Quick Start Guide’s first-run path, including its order, required steps, optional features, and level of detail.
  • Finding: These concerns form one review rather than three separate tasks. A new user can understand the main path—onboarding, permissions, generator setup, optional integrations, load planning, and starting a run—but the guide is broader than a true start-to-finish quick start. The basic order is logical, yet the separate Home Assistant management flow appears before the first-run section, and advanced estimating and maintenance content follows the core task without a strong separation. The guide communicates valuable benefits, but technical details dilute the essential message: configure a generator, start a run, and know how much runtime remains. The EN, FR, and ES DEV guides now begin with an explicit first-run path and identify advanced topics as optional.
• 3.2 Analyse the guide’s typography, screenshots, callouts, spacing, and visual hierarchy.
  • Finding: The published page has a clear heading hierarchy, readable body text, consistent spacing, separators between major topics, and useful bold labels for actions. However, it contains no instructional screenshots or visual callouts, so the reader must translate text into the app interface. The page also renders two table-of-content blocks, which is redundant, and its repeated numbering restarts at 1 in each major topic. Visual hierarchy would improve if the minimum path were visually separated from optional and advanced reference sections.
• 3.3 Analyse the Quick Start Guide on mobile screens for readability and ease of following instructions.
  • Finding: At a 390 px-wide mobile viewport, the guide has no horizontal overflow; the article fits within a 334 px content column, headings wrap within the column, and the page remains readable. The main mobile limitation is length and text density rather than broken layout: a new user must scroll through many paragraphs and lists without screenshots or compact step cards. Mobile usability would benefit most from a shorter first-run path, expandable advanced sections, and more visual guidance rather than a major responsive redesign.
• 3.4 Evaluate whether to capture a small, maintainable set of GenDash screenshots from Xcode and the iOS Simulator, then add them to the shared Images folder and the EN, FR, and ES Quick Start Guides if justified.

4. User Manual#

• 4.1 Analyse whether the User Manual is complete, logically organized, and easy to navigate.
  • Finding: The manual is comprehensive, covering licensing, the product model, onboarding, generator setup, Home Assistant, preferences, environment, notifications, backup, load planning, sessions, history, Live Activities, fleet management, maintenance, reset, FAQs, and real-world examples. Its 19 major sections are broadly logical, but the 10,000-word scope makes it read more like an encyclopedia than a manual for everyday use. The published page also renders two table-of-content blocks, creating redundant navigation. The main opportunity is to preserve the coverage while improving grouping, entry points, and scanning.
• 4.2 Analyse whether the manual clearly explains GenDash features, supported hardware, integrations, and expected user outcomes.
  • Finding: Coverage is strong. The manual explains gasoline, propane, natural gas, diesel, and battery systems; the generator library and custom profiles; Home Assistant; appliance loads; estimating; sessions; fleet management; maintenance; backups; and Live Activities. It generally connects each feature to an outcome such as more accurate Time to Empty, safer load planning, or better outage awareness. The volume of detail can obscure the most important outcomes, so each major section would benefit from a short “what this helps you do” introduction.
• 4.3 Analyse whether technical instructions and terminology are understandable to the intended user.
  • Finding: Instructions are concrete and often supported by examples, field-by-field explanations, and safety notes. However, the manual assumes a technically confident reader and introduces many terms—TTE, Seed Library, LAN/WAN, Long-Lived Access Token, SwiftData, rated versus surge watts, load curves, and kWh/Wh—across a long document. The intended user can follow it, but first-use definitions or a small glossary would reduce cognitive load. UI labels should also remain consistent with the current app.
• 4.4 Analyse the manual’s typography, headings, screenshots, spacing, and visual hierarchy.
  • Finding: The published page has a strong heading hierarchy, bold action labels, useful tables, and safety/privacy callouts. It contains no instructional screenshots or diagrams, so the manual is entirely text-led apart from the site icon. The 19-section length, dense paragraphs, repeated nested headings, and duplicate table of contents make the visual experience heavy. A small number of stable visuals could help, but the maintenance cost should be weighed against the benefit; clearer section summaries and selective callouts are the lower-maintenance improvement.
• 4.5 Analyse the User Manual on mobile screens for readability, navigation, and image sizing.
  • Finding: At a 390 px-wide mobile viewport, the page itself has no horizontal overflow; the article fits within a 334 px content column and headings wrap correctly. There are no instructional images to resize. The main mobile weaknesses are the manual’s length, dense text, and large number of links, which make navigation and scanning tiring. The generator model table is slightly wider than its mobile content area and may need a small table-specific overflow check, but no major responsive failure was observed.

5. Privacy Policy#

• 5.1 Analyse whether the Privacy Policy clearly explains what GenDash collects, stores, and processes.
  • Finding: The policy clearly states that GenDash does not collect generator telemetry, financial information, or personal data on its own servers, and that app data is stored locally. It does not yet describe location data used for weather lookups, the Open-Meteo service, exported backup files, or the information submitted through the website contact form. The policy should distinguish app processing from website and support-service processing.
• 5.2 Analyse whether the policy accurately describes local-only app processing, offline operation, and the absence of user accounts.
  • Finding: The local-first, offline-ready, and no-account claims are generally clear. The Home Assistant statement is too narrow because the app supports a user-configured remote URL as well as a local-network URL. The policy should explain that Home Assistant data goes to the user’s own configured server, locally or remotely, and that internet access is also used for weather data when automatic location mode is enabled.
• 5.3 Analyse whether the website’s analytics and external services are addressed accurately.
  • Finding: No analytics, advertising, or tracking code was found in the site source, but the policy should state whether Cloudflare web analytics and hosting logs are enabled or disabled. The contact page sends form submissions to a Google Apps Script endpoint, which is an external service and is not mentioned. The policy should also identify Apple App Store processing, the Open-Meteo weather API, the user’s Home Assistant server, and the Google contact-form service with appropriate links to their policies where relevant.
• 5.4 Analyse whether the policy is readable, trustworthy, and appropriate for the intended audience.
  • Finding: The six short sections are easy to scan and use plain language. Trust would improve with an effective date and last-updated date, a clear description of the developer/data controller, a more precise scope for deletion and retention, and a note that exported backups may contain sensitive generator, history, and Home Assistant configuration data. The EN page uses H3 headings for its main sections while FR and ES use H2 headings; the heading level should be standardized across languages.
• 5.5 Analyse the Privacy Policy on mobile screens for readability and navigation.
  • Finding: The page is short, text-based, and unlikely to have a major mobile layout problem. It does not need a table of contents. The main mobile improvements are maintaining comfortable line length, making the support email a clear tap target, and checking that any added service-policy links wrap cleanly without horizontal overflow.

6. About & Contact#

• 6.1 Analyse whether the About & Contact page explains the motivation behind GenDash clearly and concisely.
  • Finding: The page explains the motivation well: the creator describes the frustration of estimating generator fuel during outages and the goal of providing a reliable, offline-first tool. The message is credible, but the two paragraphs are longer than necessary and the core purpose could be stated more quickly.
• 6.2 Analyse whether the page builds trust without becoming unnecessarily personal or lengthy.
  • Finding: Identifying the independent creator and emphasizing privacy builds trust. The references to “300 hours” and “more than 1000 modifications” are personal and may become outdated; they are optional proof points rather than essential information. The page presents an individual creator but the form says “our support team,” which should be made consistent.
• 6.3 Analyse whether the support email and Launch Mail App link are easy to find and use.
  • Finding: The email address is prominent, has a Copy button, and has a separate mailto button. The displayed email itself is not clickable, and the Clipboard API has no fallback if copying is unavailable. The French button text “Lancer l’application” is ambiguous; it should clearly mean opening the mail app. The EN, FR, and ES buttons should use equivalent wording.
• 6.4 Analyse whether the page communicates how support requests are handled.
  • Finding: The page says that support will reply by email, but gives no expected response time or guidance about what information to include. The contact form submits through Google Apps Script and uses a no-cors request, so the success message does not fully confirm that the backend accepted the message. The form’s data handling should be consistent with the Privacy Policy.
• 6.5 Analyse the page’s typography, spacing, links, and visual hierarchy.
  • Finding: The two-card layout creates a clear split between the creator/contact information and the message form. The orange action button, generous spacing, rounded cards, and dark-mode styles are consistent with the site. The page relies heavily on duplicated inline HTML/CSS across three language files, which increases maintenance cost. The decorative creator emoji is optional and should follow the same restrained visual approach as the rest of the site.
• 6.6 Analyse the About & Contact page on mobile screens for readability and ease of contact.
  • Finding: The flex-wrap layout should stack the cards on narrow screens, and the form controls use full width with comfortable padding. The main mobile checks are whether the email row wraps cleanly, whether the mail and submit buttons remain easy to tap, and whether the long creator text pushes the contact form too far down the page. No major responsive failure is apparent from the source structure, but it should be confirmed on an actual phone.

7. Final Cross-Site Review#

• 7.1 Compare English, French, and Spanish navigation, structure, and calls to action.
• 7.2 Verify Hugo front matter, titles, descriptions, dates, and canonical URLs across all pages.
  • Finding (checks 1–4): All 30 EN, FR, and ES pages—including DEV—now have front-matter titles, descriptions, dates, lastmod values, draft flags, and tags. Localized titles and descriptions are consistent, every page is set to draft: false, the six homepage files now have the title GenDash, the misspelled privaly tag was corrected to privacy, and all lastmod values were aligned with the current metadata update. Canonical URLs still require the local build/render check.
• 7.3 Check internal links, language links, missing assets, and broken links.
• 7.4 Check light-mode and dark-mode consistency across all pages.

8. Preview & Publish#

• 8.1 Analyse the best way to preview each English page locally before publication.
• 8.2 Analyse desktop, tablet, and mobile presentation before publication.
• 8.3 Analyse whether the existing pushgen workflow can publish the approved changes safely.
• 8.4 Analyse the published Cloudflare Pages site after deployment.
• 8.5 Record follow-up improvements based on the final review.

Sections 1–3 describe GenDash and pushgen. Section 4 describes DashApps and pushdash. For DashApps page content, edit /Users/marc/Obsidian/DashApps/Notes (or Images) as the source of truth. pushdash syncs that local copy over the server’s staging inputs; its default run also publishes the website source. For local-only edits, do not run pushdash.

Hugo file GenDash: Obsidian to Hugo Automated Publishing Guide

This guide outlines the infrastructure and configuration required to sync an Obsidian vault across multiple devices and automate the publishing process to a Hugo website via Cloudflare Pages.

App Store Submission Checklist#

1. Administrative & Legal#

• 1.1 Active Apple Developer Program Membership: Annual subscription required to distribute on the store.
• 1.3 App Store Connect User Access: Proper permissions for the team members managing the submission.
• 1.2 Facultative - I’ll start with the individual account - D-U-N-S Number: Unique identifier used by Apple to verify business entities for organizations.
• 1.4 Paid Applications Agreement: Signed contract required for apps with a purchase price or subscriptions, via https://appstoreconnect.apple.com/ (Demande TPS-TVQ fait 27 avril)
• 1.5 Banking and Tax Information: Verified details needed for Apple to process your earnings.
• 1.6 Public Privacy Policy URL: A web link detailing how you handle and protect user data. (https://github.com/marcoue/GenDash-Support/ and Privacy form in App store)
• 1.7 Export Compliance Documentation: Proof of clearance for apps utilizing specific types of encryption. (Via Info.plist file in Xcode)
• 1.8 Digital Services Act (DSA) Compliance: Mandatory legal registration for distribution within the European Union. (Opted out for now as it requires my personal home address)

2. Technical Requirements#

• 2.1 Latest Mandatory Xcode Version Build: The binary must be compiled with the current Apple-approved IDE.
• 2.2 Latest iOS SDK Compatibility: Ensuring the app supports current system APIs and frameworks.
• 2.3 App Privacy Manifest: A .privacyinfo file documenting the data types accessed by your code.
• 2.4 SHA-256 Certificate Support: Modern security standard required for app signing certificates.
• 2.5 64-bit Architecture Support: Technical requirement for compatibility with all modern iOS hardware.
• 2.6 Optimized Binary Size: Monitoring the final build to stay within cellular download limits. (When app is completed)
• 2.7 Bitcode Disabled: Adherence to modern standards where bitcode is no longer required for thinning.

3. Metadata#

• 3.1 App Name: The primary title of the application as it appears in search.
• 3.2 Subtitle: A secondary tagline used to summarize the app’s purpose.
• 3.3 Description: A full text overview of features and functionality for potential users.
• 3.4 Keywords: A hidden list of terms that improve the app’s search discoverability.
• 3.5 Promotional Text: A short, editable field to highlight news or limited-time updates.
• 3.6 Marketing URL: A link to your product’s landing page or company website.
• 3.7 Support URL: A direct link where users can go for technical help or FAQs.
• 3.8 Version Number and Build String: Incremental identifiers for tracking your releases and builds.
• 3.9 Category Selection: Tags that determine which store departments the app resides in.

4. Visual Assets#

• 4.1 App Icon: A 1024x1024 px image representing the app on home screens.
• 4.2 Screenshots for 6.7" Display: Visuals for the largest iPhone models like the Pro Max.
• 4.5 iPad Screenshots: Required imagery if your app is compatible with iPadOS.

5. App Review Information#

• 5.1 Demo Account Credentials: Login data provided to allow reviewers to access hidden features.
• 5.2 Review Notes: Extra instructions to help the reviewer understand complex workflows.
• 5.3 Reviewer Contact Information: Name and number for the person Apple should call with questions.
• 5.4 Hardware Requirements: Documentation of any external hardware needed for the app to work.

6. Privacy & Content#

• 6.1 Privacy Nutrition Labels: A summary of what data is collected and how it is linked.
• 6.2 Accessibility Nutrition Labels: A declaration of the app’s support for assistive technologies.
• 6.3 Age Ratings: A self-assessment used to determine content suitability for different age groups.
• 6.4 App Tracking Transparency (ATT) Prompt: The system-level request for permission to track user data.
• 6.5 Content Rights: Legal confirmation that you have the rights to use all displayed content.

7. Pricing & Availability#

• 7.1 Pricing Tier Selection: The defined cost for purchasing the app or in-app services.
• 7.2 Regional Availability: A list of specific countries where the app will be available.
• 7.3 Pre-order Status: A setting to allow users to sign up for the app before launch.
• 7.4 Release Methodology: A choice between manual, scheduled, or automatic publication.

8. Critical Alerts Entitlement & Implementation#

• Submit the “Critical Alerts Entitlement” Request Fill out the official Apple form providing a safety-based justification for why GenDash fuel/status alerts must bypass the mute switch.