Capability Router

The base workspace contains dynamic authentication, theming, an error boundary, an authenticated welcome view, and three packages: frontend, data, and shared. It has no live data source, persistence, charting, or trusted server-side logic until a capability pack adds it.

Decide the source first

Preserve what the user asked to use. Do not select a pack from words such as "dashboard" or "workflow" alone.

Never fabricate identifiers, schemas, query output, or business values. Do not ask the user to describe a discoverable schema. Use the installed tools and version-matched docs to inspect it.

A declared semantic-model app needs its intended model. Sample data is a separate, user-confirmed route, not a fallback for a missing model.

Select the capabilities

Capabilities compose. An app that stores records, reads a semantic model, charts results, and calls a trusted API needs four separate pack invocations. The current scaffolder accepts one pack per invocation. Run pack commands serially because they mutate workspace manifests, root scripts, and service configuration.

Use data-modeling for records the app owns. Use connectors for records that already exist in a supported Fabric source. Use visuals for rendering, regardless of whether rows come from sample data, Rayfin data, or analytics. Use functions only for trusted code, secrets, app identity connections, or server-side calls.

Kusto and KQL are not supported in this release. Say so and stop rather than swapping in another source.

Optional consolidated install

When several packs are selected, you may avoid a separate install after each pack without inventing a multi-pack command:

1. Run each selected npm run pack:add -- <name> --no-install command serially.
2. Inspect every result for preserved files and stop if any pack reports one.
3. After all packs apply cleanly, run one install from the workspace root:

npm install --ignore-scripts --no-audit --no-fund

This is a manual authoring optimization, not durable pack caching. The consolidated install does not write the per-pack success markers, so a later ordinary pack reapply may install again.

Preserve workspace ownership

Run pack and lifecycle commands from the workspace root. The pack manifest selects the package manifest that owns its dependencies:

• Frontend and connector dependencies belong in packages/frontend/package.json.
• Decorated entities belong in packages/data, while browser-safe record contracts belong in packages/shared.
• The functions pack creates packages/functions and composes it into the root build and typecheck scripts.

Do not create nested lockfiles or install dependencies separately inside workspace packages. Do not import decorated entity classes into frontend code.

Apply and hand off

Apply selected packs before editing files they seed. If a pack preserves an existing file, report it and stop instead of assuming the pack's contract is installed. Use --force-seeds only with explicit user approval.

After routing:

1. Read the owning skill for each selected capability.
2. Read the relevant seed files and exact installed package documentation in parallel where independent.
3. Establish a runnable shell in packages/frontend with honest loading states, preserving protected hosting and the dynamic auth gate.
4. Verify real query or operation output before writing code that consumes its fields.
5. Integrate data, interactions, and polish, then follow AGENTS.md for final validation and deployment.

Substantial independent discovery or implementation may be delegated behind a clear interface. Do not fan out a tiny app or tightly coupled flow merely because parallel agents are available.