minutework 0.1.13 → 0.1.14

package/assets/claude-local/CLAUDE.md.template

@@ -13,6 +13,9 @@ Read these exported skills before making MinuteWork-specific architecture
 decisions from a generated workspace:
 
 - `skills/generated-workspace-architecture.md`
+- `skills/shell-architecture.md` when the request touches member-facing UI,
+  operator workflows, threads, channels, cards, dashboards, approvals, or "do
+  we need a separate frontend?" questions
 - `skills/runtime-capability-inventory.md`
 - `skills/layering-and-import-modes.md`
 - `skills/capability-gap-reporting.md`
@@ -23,6 +26,28 @@ decisions from a generated workspace:
 - `skills/email-ingress-and-thread-routing.md` when the request touches inboxes,
   aliases, email/SMS/chat routing, or thread-based communication
 
+## Shell-First UI Default
+
+- For member-facing collaboration and operator work, check shell fit first.
+- The primary collaboration surface is the gateway shell under
+  `/w/[workspace_slug]`, not a bespoke standalone tenant frontend.
+- First ask whether the request should be a shell extension:
+  - thread metadata
+  - cards / attachments in the thread stream
+  - agent skills in thread context
+  - contextual right-rail detail
+  - server-level shared state or catalogs
+- Only propose standalone `tenant-app` UI after explicitly checking shell fit
+  and documenting why the request is an exception.
+- If shell fit is correct but the generated workspace cannot directly author the
+  needed shell extension, keep the shell-first proposal and record a capability
+  gap instead of silently falling back to standalone `tenant-app`.
+- Common exception paths are:
+  - public marketing
+  - public intake for non-members
+  - embeddable widget
+  - explicit request for a separate standalone client/app
+
 ## Starter Choice Matrix
 
 The shipped product unit is an `app pack`. `tenant-app` and `sidecar` are
@@ -30,7 +55,7 @@ implementation surfaces inside that pack.
 
 | If the request is mainly about... | Choose | Why |
 | --- | --- | --- |
-| Authenticated web UI, dashboard, forms, settings, tenant portal | `tenant-app` | This is the Next.js UI/BFF surface. |
+| Authenticated standalone web UI, separate tenant portal, custom client, or other explicit shell exception | `tenant-app` | This is the Next.js UI/BFF surface after shell fit has been checked. |
 | Public website, pricing, docs, blog, landing pages | `tenant-app` | Public web belongs in the web app surface; do not create a sidecar just to render pages. |
 | Internal API, webhook handler, worker, cron, queue consumer, ingestion, Python-heavy compute | `sidecar` | This is backend/runtime logic, not a browser app concern. |
 | Web app plus background jobs, integrations, AI processing, or internal APIs | `both` | Put UI in `tenant-app`; put backend execution in `sidecar`. |
@@ -39,7 +64,9 @@ implementation surfaces inside that pack.
 
 ## Default Rule
 
-If unsure, start with `tenant-app`.
+If unsure, check shell fit first. Only start with `tenant-app` after the request
+has been confirmed to be a public surface or an explicit standalone-shell
+exception.
 
 Prefer declarative schema/manifests first. Add `sidecar` only when you can name
 a concrete backend responsibility such as:

package/assets/claude-local/skills/README.md

@@ -22,6 +22,7 @@ receive:
 Generated-workspace-first guidance should live here, especially:
 
 - `generated-workspace-architecture.md`
+- `shell-architecture.md`
 - `runtime-capability-inventory.md`
 - `layering-and-import-modes.md`
 - `capability-gap-reporting.md`

package/assets/claude-local/skills/app-pack-authoring.md

@@ -8,6 +8,15 @@ An `app pack` is the shipped product unit.
 - Start with declarative schema/manifests and add code surfaces only when needed.
 - Use `tenant-app` for the combined public-site plus private-app web surface.
 - Use `sidecar` for internal APIs, workers, integrations, or Python-heavy compute.
+- For member-facing collaboration and operator workflows, check shell fit first
+  before proposing standalone `tenant-app` routes or dashboards.
+- Prefer thread metadata, cards/attachments, agent skills, right-rail detail,
+  and server-level state when the request belongs inside the shell.
+- Only use standalone `tenant-app` UI by default for public surfaces or when the
+  request explicitly asks for a separate client/app.
+- If shell fit is correct but this generated workspace cannot directly author
+  the shell extension, record a capability gap instead of silently turning the
+  request into a standalone `tenant-app` exception.
 - Treat `mw.core.site` as a runtime baseline capability and compose against it
   instead of trying to install it from the workspace.
 - Reuse existing runtime AI capabilities before adding direct model/provider

package/assets/claude-local/skills/generated-workspace-architecture.md

@@ -17,6 +17,16 @@ the monorepo or a live tenant runtime.
 - `tenant-app` and optional `sidecar` are implementation surfaces inside the
   tenant product, not the whole architecture.
 - `tenant-app` is the combined public plus private web starter.
+- For member-facing collaboration and operator work, the primary product surface
+  is the gateway shell under `/w/[workspace_slug]`. Do not default to a bespoke
+  standalone tenant frontend when the work belongs in shell threads, cards, or
+  metadata.
+- Public routes and explicit standalone-client exceptions still belong in
+  `tenant-app`; check shell fit first before taking that path.
+- If shell fit is correct but this generated workspace cannot directly author
+  the needed shell extension, keep the shell-first proposal and record a
+  capability gap instead of silently converting the work into standalone
+  `tenant-app` UI.
 - External collaboration is a first-class system pattern. Do not treat guest
   participants, inbound aliases, or shared threads as ad hoc product features.
 - `mw.core.site` is a runtime baseline capability; public site authoring should

package/assets/claude-local/skills/shell-architecture.md

@@ -0,0 +1,58 @@
+# Shell Architecture
+
+Use this skill when the request touches member-facing UI, operator workflows,
+threads, channels, inboxes, guest collaboration, approvals, dashboards, or
+"should this be a separate frontend?" questions.
+
+- Default to the member shell first. For collaboration and operator work, the
+  primary product surface is the gateway shell under `/w/[workspace_slug]`, not
+  a bespoke standalone tenant frontend.
+- Treat these nouns as the default mental model:
+  - **Server**: the product-facing private tenant space
+  - **Channel**: a conversation surface inside the shell
+  - **Thread**: the unit of work inside a channel
+  - **Entry / attachment / card**: the UI that renders inside a thread stream
+  - **Member / guest / shadow participant**: visibility and participation roles
+  - **Agent**: may appear as a shell channel in the current shell model
+- Current shell truth:
+  - the shell is the **primary** collaboration surface, not literally the only
+    UI in the repo
+  - `/w/[workspace_slug]` redirects into the channel shell routes
+  - the current v3 shell implements a left rail, sidebar, main thread area, and
+    right rail
+  - the current shell proves a fixed agent-like channel set (`superagent`,
+    `builder`, `website-admin`); do not assume arbitrary runtime agents already
+    auto-materialize as channels unless code or runtime inventory proves it
+- For member-facing operator work, first ask whether the request fits as a shell
+  extension:
+  - thread metadata extension
+  - rich message card / attachment
+  - agent skill invoked in thread context
+  - server-level shared state or catalog
+  - right-panel contextual detail
+- Do **not** default to standalone `/app/*` dashboards or object-management
+  routes when the work belongs in threads, cards, metadata, or agent-driven
+  conversation.
+- Standalone `tenant-app` UI is an exception path, not the first proposal.
+  Consider it when:
+  - the user explicitly asks for a separate standalone client
+  - the surface is public marketing
+  - the surface is public intake for non-members
+  - the surface is an embeddable widget
+- If shell fit is correct but this generated workspace cannot directly author
+  the shell extension, keep the shell-first recommendation and record a
+  capability gap instead of silently converting the request into standalone
+  `tenant-app` UI.
+- Be precise about terminology:
+  - product/server space: **Server** / **Tenant** in platform docs and models
+  - generated local repo: **developer workspace**
+- Do not overclaim current platform reality:
+  - shell-first is the intended default
+  - the current shell still has static/mock sections and fixed routes
+  - not every right-rail or agent/channel extension is a generalized registry
+    yet
+- When in doubt, inspect:
+  - frontend shell routes and components
+  - platform `channels` / `threads` models
+  - runtime `ThreadRuntimeBinding` and thread-post models
+  - shadow/public-intake/reference contracts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "minutework",
-  "version": "0.1.13",
+  "version": "0.1.14",
   "description": "MinuteWork CLI for workspace scaffolding, local preview workflows, and hosted preview deploys.",
   "type": "module",
   "bin": {