Make The Framework modular (Vike-style extensions)

[suleimansh]

Make The Framework modular, similar to Vike: installed framework-* packages self-register instead of the CLI hardcoding the list.

Decisions (settled)

• Agnostic core. Nothing is Vike-gated. Capabilities are framework-agnostic.
• Framework = a skill. A framework isn't a special adapter package. It's just a skill = a pointer to its llms.txt (e.g. https://vike.dev/llms.txt for Vike, the equivalent for Next). The old "adapter" axis is gone.
• Flat naming. framework-sentry, not framework-tracking-sentry.
• Open Loop / presets / marketplace / modes moved to Open Loop: customizable prompts + flows, domain presets, marketplace #204. This issue stays scoped to the extension SPI.

So the model is two things: capabilities (auth, data, ...) that self-register + skills (doc pointers for framework/domain knowledge). Skills are the shared unit with #204.

Where it's hardwired today

packages/framework/src/run.ts pins the composition:

const { preset, detection } = builtinPresetRegistry().select(opts.signals ?? {})
const personas = detection.framework === 'Vike'
  ? presetPersonas(preset, vikeExtensionPersonas)   // fixed list, Vike-gated
  : presetPersonas(preset)

The registry and the extension list are pinned in code, so no third party can publish framework-next or framework-drizzle and have it auto-compose. The substrate is already there (Preset detection + Persona capabilities + registries in @gemstack/ai-autopilot), it just isn't exposed.

What to build

A public FrameworkExtension unit (capability) that bundles:

• detection signals (deps/files) that decide when it activates
• persona(s) it contributes to the agent frame
• optional serve / checklist / deploy contributions
• optional skill(s) it pulls in (e.g. a data extension can register the ORM's llms.txt)

The CLI discovers installed framework-* packages, registers them, and composes whatever matched, instead of hardcoding vikeExtensionPersonas. Framework knowledge comes in as a skill, not a gate.

Scope

• Define the FrameworkExtension SPI (defineFrameworkExtension)
• Define the skill unit (pointer to an llms.txt) and how extensions/presets register skills
• Discovery: find + register installed framework-* packages (plus explicit opt-in via config)
• Compose matched extensions in run.ts, drop the hardcoded vikeExtensionPersonas / Vike gate
• Ship the built-ins (auth, data) as extensions and Vike as a skill through the same seam to prove it
• Docs: how to author and publish a framework-* extension

Related: #204 (Open Loop), #186 (compose framing), #110 (AI framework epic).

[suleimansh]

One clarification on what "an extension" is here, because framework-next and framework-auth read like the same kind of package but aren't. There are two axes, same split Vike itself has:

1. Framework adapters (a Preset today): the "which meta-framework" knowledge + detection.

• framework-vike, framework-next, framework-nuxt, framework-sveltekit
• Parallel to vike-react / vike-vue being renderer adapters. Exactly one is active per app.

2. Capability extensions (a Persona today): a cross-cutting concern, framework-agnostic.

• framework-auth, framework-data, framework-crud, framework-notifications
• Parallel to vike-auth / vike-data. framework-auth is NOT a meta-framework: it teaches the agent to compose a real auth lib when the app needs sign-in, instead of hand-rolling sessions/cookies. Many can be active at once, on top of whichever adapter is active.

framework (core: loop, driver seam, dashboard)
  framework-vike / framework-next    <- adapters (Preset)
  framework-auth / -data / -crud     <- capabilities (Persona)

Two design questions this raises:

• Naming. Adapters and capabilities share the framework- prefix but are different units. Vike lives with a flat vike-* namespace, so this is fine, but if we want them visually distinct we could reserve a word for capabilities. Flagging, not deciding.
• Are capabilities framework-agnostic? Today the capability personas (vikeAuthComposer, vikeDataModeler) are Vike-specific: they say compose vike-auth / vike-data. A real framework-auth either stays Vike-gated for now, or the capability is agnostic and the adapter supplies the implementation (compose vike-auth on Vike, something else on Next). My lean is agnostic capability + adapter-provided implementation, same shape as the core. That is the main thing to settle before building the SPI.

[suleimansh]

@brillout WDYT

[brillout]

Naming => my gut feelings says flat (framework-sentry instead of framework-tracking-sentry).

[brillout]

Essentially, what The Framework does is:

• Built-in prompts
• Flows (the loop)

Can we make it so that the user can fully customize both?

How about presets? For example:

• Preset "Software Developement"
  • A set of flows for code quality, testing, reviewing, ...
  • A set of prompts (e.g. for nudging AI to focus on code quality, security, ...)
• Preset "Web Development
• Preset "Product Managing"
• Preset "Biological Science"
• Preset "Data Science"
• ...

Also presets that are just a collection of presets (=> fine-grained composability).

So The Framework is an unopinionated and flexible frame to enable presets and built-in prompts. So basically, it's an "Open Loop" (maybe we should name like this).

How about a marketplace of presets and prompts (and maybe skills) then?

[brillout]

Maybe we can have both:

• The Framework
• Open Loop

Open Loop is my previous comment, The Framework is everything on top (hosting, the web UI, the mobile app, ...).

Business model idea: the mobile app is $1 / month.

[brillout]

Modes (parameters)

For example:

• Technical mode => whether the user is technical
  • Tailored prompts (e.g., if non-technical, the review TLDR prompt explicitly tells AI "never mention implementation details, only business flow")
  • Modified flows (e.g., if non-technical, auto-merge all PRs that don't affect business-logic)
• Autopilot mode => whether to minimize interruptions (nudge AI to only ask users for major business-logic decisions)

[suleimansh]

Flat naming, agreed.

The Open Loop + domain presets + marketplace direction is a big, exciting one, so I moved it to #204 to keep this issue scoped to the extension SPI (the mechanical bit we can ship now).

One thing still open on the SPI itself: are capabilities framework-agnostic (agnostic persona, adapter supplies the impl), or Vike-gated for now? That is the one decision that unblocks building.

[brillout]

One thing still open on the SPI itself: are capabilities framework-agnostic (agnostic persona, adapter supplies the impl), or Vike-gated for now?

Yes, I'd make it all agnostic to Vike. AFAICT Vike should just be a skill (which is, basically, just a pointer to https://vike.dev/llms.txt).

[suleimansh]

Agnostic works. And "framework = a skill pointing at its llms.txt" is a clean simplification, no framework-vike package, adapter axis gone. So SPI = capabilities (auth/data) + skills, skills shared with #204.