GitHub handoff for generated apps: prove you can continue

A GitHub handoff is complete only when another maintainer can identify the intended version, clone it cleanly, install and build it, provide fresh configuration, make an independent change, and understand which external services are not contained in Git.

In Mythos, GitHub connection and synchronization, project ZIP downloads, and manual code editing require an active paid workspace subscription. Check the current plan features before starting this procedure. Owning your generated code does not depend on keeping that subscription.

Begin with the GitHub connection or Download codebase flow, then run the exit drill below. Confirm repository ownership, branch behavior, conflict handling, and what remains after disconnecting. The presence of a GitHub button or one successful synchronization is only the start of the handoff.

“The code is in GitHub” compresses three separate promises:

Passing one does not imply the others. A repository may contain source that no longer matches the active Preview. The correct files may still depend on an undocumented package or configuration value. A clean build may still rely on a hosted database, authentication service, storage bucket, domain, or provider account the new maintainer cannot operate.

Define “handoff” for the actual transition: another engineer, another team, another organization, or a future version of yourself. The more distant the recipient, the less unwritten context you can rely on.

With the paid feature access described above, a project also needs at least one completed Build before GitHub can be connected. Open the Git view in the workspace, choose Connect GitHub, authorize Mythos through GitHub OAuth, select your personal account or an organization the authorization can access, and confirm the repository details. Mythos creates a new private repository for the project; it does not take over an arbitrary existing repository.

That boundary matters. If your organization restricts OAuth app access or repository creation, resolve that policy before treating connection as guaranteed. Do not transfer, rename, change visibility, or move an existing asset as an incidental setup step.

The same project also offers Download codebase as a source export. Download is useful for inspection or a one-time handoff, while GitHub connection adds an ongoing selected-branch synchronization path. Neither automatically exports external infrastructure.

Record the repository owner, name, visibility, default or selected branch, connection time, Mythos project, and the first matching source revision. These facts make later mismatch diagnosis possible. GitHub integration documentation is the current user-facing contract.

Mythos works with one selected branch at a time. Changes made through Mythos are sent to that branch, while direct GitHub commits on the same branch can return to the project after synchronization. Other branches remain separate until you deliberately select one.

This still leaves room for a normal Git workflow:

• create a feature or audit branch outside Mythos;
• review or experiment without changing the selected branch;
• merge through your usual repository policy;
• select another branch only when you want Mythos to work from it.

Do not assume every branch is synchronized or that changes appear instantly. After a direct GitHub commit, wait for the documented update and compare the branch name and commit shown on both sides before starting competing edits.

Keep branch protection, required reviews, and organization policy under owner control. Connecting a builder is not permission to weaken them.

A commit hash identifies one point in a repository’s history. After an export or the creation of a new repository, the history may look different even when the application files are equivalent. For a handoff, what matters is that the intended tracked files are present and the project can be reproduced.

Capture:

• the full commit hash shown in GitHub;
• the project version or Preview being handed off;
• the repository owner, name, and branch;
• a comparison of the relevant tracked files;
• the package manifest and lockfile state;
• the observed behavior tied to that checkout.

Ignore generated build directories and local caches when comparing source. Do not ignore environment templates, migrations, or public assets that the application actually needs.

If the versions differ, stop and determine whether synchronization is still pending, someone made an intentional external commit, or a conflict needs resolution. Do not force-push simply to make the labels agree. An overwrite can erase the evidence needed to reconcile the work safely.

Create a branch outside the selected Mythos branch and make a harmless, reviewable change, such as improving a README setup note or adding a source-level test. The goal is not to modify the product for its own sake; it is to prove ordinary Git behavior remains available.

Check that you can:

1. create and push the branch with normal Git tools;
2. open and review its diff independently;
3. run relevant checks from that branch;
4. leave it untouched by Mythos while another branch remains selected;
5. merge or discard it through your own repository policy.

For a stronger continuation test, implement one bounded product correction on the branch, run its acceptance case, and have a second maintainer reproduce it. Keep this separate from the sync test so you can distinguish Git ownership from Mythos import behavior.

Do not select the experimental branch in Mythos merely to see what happens if doing so would change active project source. Branch selection is an intentional project operation, not a passive inspection.

Give the recipient the repository URL and only the written handoff record. The original builder should observe but not fill gaps. Time-box the audit so unclear assumptions become visible.

Every question the recipient must ask becomes a documentation or ownership gap. Do not hide those questions during the exercise; capture them and improve the handoff record.

Use a new directory and the repository’s declared runtime. Inspect package.json before choosing commands:

git clone <private-repository-url>
cd <repository>
git switch <handoff-branch>
npm install
npx tsc --noEmit
npm run build

Current Mythos-generated projects use Vite, React, Tailwind, and TypeScript. The template may not initially include a package lockfile, so npm ci is not automatically the correct first command. Review the dependency resolution, commit a deliberate lockfile, and then use npm ci for repeatable later installs.

Reject hidden prerequisites:

• a package linked from the original machine;
• source generated only at runtime but absent from the repository;
• an environment variable known only from browser storage or chat;
• an uncommitted migration;
• a build that succeeds only because a stale output directory exists.

Delete local build output before the final verification, or rely on a truly fresh clone. Record runtime and package-manager versions with the result.

Git contains files and history. It does not automatically transfer:

• cloud projects, runtime services, or deployment permissions;
• databases, auth tenants, storage buckets, or their data;
• DNS zones, custom domains, or certificates;
• provider OAuth apps and callback configuration;
• environment variables, secret values, or secret-manager bindings;
• monitoring projects, alert recipients, or incident history.

For every external dependency, name the provider, resource owner, environment, purpose, configuration reference, and recovery path. State whether the recipient will reuse it, recreate it, or replace it. Any transfer, visibility change, or ownership change requires explicit owner authorization for the exact asset and destination.

Avoid saying “deploy anywhere” until you have tested a specific target. Standard Vite source improves portability, but hosting still needs routing, environment, security headers, caching, and provider configuration appropriate to that target.

Create an environment inventory without exposing credentials:

The names are illustrative; use the project’s actual validated contract. For each variable, document whether it is public at build time or private at runtime, who can provision it, and what failure looks like when it is absent. Never place secret values in Git, chat, issue text, command arguments, screenshots, or client bundles.

Use provider-native secret references and least-privilege bindings. The recipient should create or receive approved access through the provider, then verify presence without printing the value. Rotate credentials only through an authorized operational process; a source handoff does not imply authority to change production secrets.

A running clone with an empty database is not necessarily a complete handoff. Define whether the recipient needs schema only, synthetic development data, or authority over an existing production data store.

The handoff record should include:

• migration location, ordering, and replay command;
• supported application and schema compatibility window;
• seed-data rules and prohibition on copying production records casually;
• backup schedule and a tested restore procedure;
• retention, export, and deletion responsibilities;
• external object storage and lifecycle rules;
• rollback behavior for data-changing releases.

Source history cannot undo a destructive database statement or provider-side mutation. Use expand-and-contract migration practices for live systems, and test recovery before the transition. Never export user data or duplicate a database merely because code ownership is changing; that requires separate explicit authority and privacy handling.

When Mythos and GitHub both have incompatible changes on the selected branch, Mythos surfaces a conflict instead of silently overwriting one side. Treat the conflict as a state to reconcile, not a cue to retry forcefully.

Use a disposable, non-product line to learn the flow:

1. confirm both sides and the selected branch;
2. make one harmless external commit;
3. wait for synchronization and verify it appears;
4. avoid simultaneous Mythos mutation during the observation;
5. if a conflict is surfaced, preserve both versions and resolve deliberately.

Do not manufacture a destructive conflict on important work. Never force-push or rewrite protected history without exact owner authorization.

Finally, test the exit: disconnect Mythos from the workspace Git view and verify the repository remains in the chosen GitHub account or organization. Disconnect removes the connection; it does not delete the repository. Confirm who now owns deployments, updates, secrets, and incidents. Reconnect only when the future sync relationship is intended.

A useful record is short enough to stay current and precise enough to operate:

Project:
Repository:
Visibility:
Handoff branch:
Exact reviewed revision:
Matching candidate or release:

Runtime and package manager:
Install:
Typecheck:
Test:
Build:
Start:

Critical path:
Known limitations:

Configuration names and owners:
External services and owners:
Migration and seed commands:
Backup and restore owner:
Deployment target and authorized release process:
Monitoring and incident owner:

Mythos connection state:
Last selected branch:
Last verified sync:
Recipient:
Acceptance date:

Store the record where maintainers will find it, update it when contracts change, and link to provider-specific runbooks rather than copying secret or volatile state. The recipient should sign off on observed evidence, not just receipt of the repository URL.

A successful clone and build does not prove production configuration, external data, domain control, or operational access transferred. It does not certify the generated source as secure, accessible, or correct. It only proves the evidence you actually collected.

Two-way selected-branch sync is convenient but not a replacement for repository policy, review, backups, or release controls. Asynchronous synchronization also means a brief mismatch can be normal; identify exact revisions before acting.

If the recipient cannot obtain the required external-resource authority, the handoff may still be useful as source ownership but incomplete as service operation. Say so explicitly rather than transferring resources or weakening controls without separate permission.

Can Mythos connect to an existing repository?

The current documented flow creates a new private repository for the project under the selected personal account or organization. Do not plan an existing-repository takeover from this contract.

Does every GitHub branch sync with Mythos?

No. One selected active branch syncs in both directions. Other branches remain untouched until you explicitly select one.

Is synchronization immediate?

No guarantee of instant import should be assumed. Direct GitHub changes can arrive asynchronously. Verify exact source before starting competing edits.

What happens if both sides change?

Mythos surfaces a conflict rather than silently overwriting source. Preserve both sides and reconcile deliberately.

Does disconnecting delete the GitHub repository?

No. The repository remains in the chosen account or organization. Disconnecting removes the Mythos connection.

Is GitHub enough to recreate production?

Usually not. You also need documented configuration, external services, schema and data handling, deployment settings, monitoring, and authorized access.

Current Mythos documentation used for this guide:

• GitHub integration
• Building and editing
• Workspace editor
• Version history
• Troubleshooting

The clean-checkout audit, configuration inventory, and transition record are editorial handoff practices. They do not imply that GitHub contains or transfers external services.

Continue with:

• From prompt to a production candidate
• How to evaluate AI app builders beyond the first demo
• How to iterate without breaking the rest of your app