Discussion: Micro builds personal apps that compose Mu services

Product thesis

A user should be able to tell Micro what they need and have it build, test, publish and maintain an app for them. This is a useful product outcome, not merely generated HTML. Mu supplies reusable capabilities; Micro helps turn them into a coherent personal experience.

Mu is the runtime, Micro its native personal assistant and first product. The built-in interface and the hosted Assistant app are a discovery process. Keep improving the built-in product while exploring what static apps can do. Do not commit to replacing every service UI or creating permanent competing assistant products.

Related: #1644 (shared agent loop, delegation and verified completion), #1630 (external runtime extensions), #1513 (service runtime).

Services and apps

Services supply data and operations. Their generic pages remain useful. Apps compose those capabilities into experiences for particular people and use cases; built-in versus user-created is not the fundamental architectural boundary.

Today a service page, Home dashboard or conversational tool call can expose capabilities without joining them into the experience someone actually needs. An app can provide that missing interaction across three to five services.

Examples to explore:

• A journey app combining maps, directions, transport arrivals and journey planning into one usable trip experience. Separate route and bus lookups are insufficient.
• A video app tailored to a parent's children, with appropriate discovery, saved searches and viewing choices. Keep this experience out of the generic video service unless a genuinely reusable capability is missing. Presentation filters alone are not an enforcement boundary.
• Fork the Assistant app and customise its appearance and behavior for yourself while reusing Micro and the runtime APIs.
• Notes, blog or maps app experiments can test alternative interfaces, but a wholesale rewrite of service pages is not the objective.

The app-building loop

• Micro discovers the apps tools and relevant service APIs from a natural-language request.
• Retrieve actual existing source when modifying an app; preserve a recoverable original.
• Work in a persistent, scoped workspace with shell tools and iterative file edits, not a one-shot generation constraint.
• Preview the hosted/sandboxed app and exercise real interactions using browser tools. Account for iframe permissions, API errors, mobile layout and authentication.
• Revise based on test results; retain useful state across multi-step/background work.
• Publish through the apps API without rebuilding/redeploying Mu.
• Return a working URL, evidence of the requested outcome and honest limitations. A passing static apps_test is not proof the feature works.
• Support subsequent changes against the same app identity, with source versions and rollback.
• Explore personal forks with separate app identity and private data by default. Copying an app must not silently clone secrets, share private records or broaden Micro's authority.

The existing Assistant Copy-button assignment is the first small maintenance experiment. It was marked done without a useful implementation/publishing report; #1644 records the completion gap. Do not hide failures in this experiment by having a different coding agent do the work and attribute it to Micro.

Boundaries to discover

Static HTML/CSS/JavaScript can compose existing APIs. Server-side secrets, durable jobs or missing operations must live behind an appropriate service/runtime boundary; they cannot be safely invented inside a public app bundle. Record actual blockers as they emerge rather than prebuilding a general execution platform.

Distinguish reusable missing service capabilities from one app's layout or domain policy. An app should not need to change Mu simply to arrange existing operations into a different experience.

Keep permissions understandable: private by default, deliberate publication/sharing, scoped access to the user's services. Publishing app code is separate from publishing its users' data.

Source ownership/versioning must be clear. Explore Git-backed source and deployment later (potentially a separate apps/product repository), once the Assistant experiment proves useful. Do not require a marketplace, custom build language, mandatory app scaffolding or runtime redeploy for each UI iteration.

Experiments and success criteria

1. Micro successfully modifies and verifies an existing app through its own tools.
2. Micro creates a personal Assistant fork without altering the original or escalating access.
3. Build one small composite app from an actual user need: journey planning or a family video experience. Choose the narrowest usable slice.
4. Have the user request a follow-up change, then verify revision and rollback.

Success means the user can describe a need, use the resulting app and ask Micro to improve it. Assess reliable task completion, usability, time to a verified update, permissions and maintainability—not screenshot quality alone.

Broader direction, without overbuilding now

The same runtime can support a later Workspace-like business product: custom domains, customised channels/feeds, own keys/agents and paid external integrations. These should build on the consumer foundation and sane defaults rather than adding enterprise complexity to every personal app. Self-hosting remains first-class. The longer-term intelligent computer grows from this foundation; the current work is proving the assistant can build useful things.

No implementation file is named. Start by reviewing the existing Assistant Copy-button assignment, apps_test, the apps API, and related issues #1644, #1630, and #1513. Choose one narrow experiment and define completion as a verified app update with a working URL, evidence of the requested outcome, and honest limitations.