Discussion: Git as an app publishing interface, with explicit source and release ownership

Related: #1645, #1646. Proposal from Asim: apps should be developable outside Mu and published using familiar tooling, just as Files supports SFTP, Shell SSH and Mail SMTP. Git is a possible additional interface to the apps capability, not necessarily justification for a general code-hosting service.

Existing foundation

Apps already retain bounded version snapshots, restore versions and support forks. Today raw apps are HTML artifacts, not arbitrary deployable repositories. Git source history and published app releases are different things.

Thesis and holes to resolve

• A repository does not specify what runs: distinguish ready-to-serve artifacts from source requiring a build. Start with an explicit entrypoint/artifact contract; do not execute arbitrary install scripts or git hooks in the Mu process.
• Git push is plausible for publishing. Full Git hosting adds clone/fetch/ref storage, authentication, quotas, concurrent writes and repository maintenance; code review/issues/marketplace are not prerequisites.
• GitHub origin plus Mu deployment remote is coherent when origin owns source and Mu stores releases pinned to commits. Bidirectional edits introduce divergence; do not silently overwrite app edits on the next pull.
• apps create from a Git URL should resolve an explicit ref to an immutable commit and record provenance. Updates should be explicit initially. Fetching a repository must not imply publication or a background subscription.
• Git transport identity must map to app ownership and deployment rights. Scope credentials narrowly; never embed repository credentials into public source or logs.
• Private repository access, outbound fetch restrictions, submodules/LFS, large files and asset paths need a bounded policy. An arbitrary URL must not become a route to internal network resources.
• Rollback should select a known published artifact rather than depend on a remote branch still existing or a rebuild producing identical bytes.
• Clarify whether a personal fork inherits only code or also configuration/data; private user data and secrets must not be copied by default.

Smallest staged experiment

1. Develop the Assistant in a normal versioned external repository and publish its built artifact through the existing apps API. Record source commit alongside a release if supported, otherwise define the missing metadata.
2. Define the artifact/manifest contract, validation, atomic publication and rollback. Preserve the current app API and agent tools as equal interfaces.
3. Add explicit import/update from a Git URL pinned to a commit if it removes real friction.
4. Consider a Git receive endpoint or git-over-SSH push only after demand warrants maintaining that protocol. Reuse existing scoped identity, not a general host shell.
5. If Mu-side editing is supported for Git-backed apps, choose an explicit model: fork/detach, or export a commit/patch for upstream review. Do not invent automatic two-way synchronization.

The product is deploying and maintaining an app. A general code service is a separate future decision. No implementation of Git hosting is requested by this discussion; the active priority remains reliable Micro app maintenance in #1646.

This is a design discussion, not an implementation task, and it names no files or tests. Start by reading the existing apps API and the active maintenance work in #1646, then evaluate the staged Git experiment and its artifact, provenance, ownership, and rollback requirements. Done would require a scoped implementation decision rather than a patch from this issue alone.