opensquid 0.5.395

package/packs/builtin/focused-react-19/manifest.yaml

@@ -0,0 +1,171 @@
+# focused-react-19 — React 19+ idioms as opt-in discipline + recall surface.
+#
+# Focused pack (kind: focused per MM.1 default) — narrow domain (React 19
+# specifically; intentionally excludes React 18 and earlier idioms which
+# often conflict with Server Components + Actions). Aggregated into the
+# `frontend-react-19-atomic` composite alongside `focused-typescript-strict`
+# and `focused-atomic-design` (DOG.2).
+#
+# Per pack-runtime.md §1.5 — focused packs are reusable units; composites are
+# the user-facing assemblies. DOG.1 ships the manifest + foundation +
+# detected_by; skills land in DOG.4 (after DOG.3 ships the seed_lessons +
+# verify_gates schema sugar).
+name: focused-react-19
+version: 0.1.0
+scope: domain
+goal: Encode React 19+ idioms (Server Components, Actions, useOptimistic, hooks-of-hooks) as opt-in discipline + recall surface for a React 19 codebase.
+description: |
+  Focused pack — narrow domain. Activates when a project's package.json
+  declares react ^19 in dependencies OR devDependencies. Aggregated into
+  the frontend-react-19-atomic composite for the v1 dogfood demo.
+
+  When react 20 ships, fork as focused-react-20 (preserves activation
+  history) rather than mutating this pack.
+
+activation_scope: project
+
+foundation:
+  tools:
+    - name: react
+      semver: '>=19'
+  domains:
+    - frontend
+    - react
+  methodologies:
+    - server-components
+    - hooks
+    - actions
+    - useOptimistic
+
+detected_by:
+  # OR semantics — react in either dependencies or devDependencies triggers.
+  # Regex matches `^19.x.x` / `~19.x.x` / `>=19` / `19.x.x` variants.
+  - kind: file_match
+    path: package.json
+    matches:
+      'dependencies.react': '^(\^|~|>=|=)?\s*19'
+  - kind: file_match
+    path: package.json
+    matches:
+      'devDependencies.react': '^(\^|~|>=|=)?\s*19'
+# DOG.4 — seed_lessons + verify_gates populated. Each lesson cites a
+# concrete React 19 source so the engine's recall surface returns
+# grounded knowledge, not opinion. Verify gates flag the two most
+# common React-19 footguns we expect to see in real code.
+seed_lessons:
+  - title: 'Server Components by default; "use client" only at the leaf'
+    body: |
+      In React 19, every component defaults to server-render. Add
+      "use client" at the leaf where interactivity is genuinely required
+      (event handlers, useState, useEffect, browser APIs). Cascading
+      "use client" from the layout level forces the whole subtree into
+      the client bundle and defeats the SC win — both bundle size AND
+      data-fetching latency regress.
+    scope: user
+    tags: [react-19, server-components, performance]
+    source: 'https://react.dev/reference/rsc/server-components'
+  - title: 'Use Actions for form mutations, useFormStatus for pending UI'
+    body: |
+      `<form action={serverAction}>` is the React 19 idiom for
+      mutations. `useFormStatus()` returns `{pending, data, method,
+      action}` for any descendant — no prop drilling. Optimistic UI
+      pairs with useOptimistic(state, reducer) for instant feedback
+      while the server-action resolves.
+    scope: user
+    tags: [react-19, actions, forms]
+    source: 'https://react.dev/reference/react-dom/components/form'
+  - title: 'useOptimistic for instant feedback during pending mutations'
+    body: |
+      `const [optimistic, addOptimistic] = useOptimistic(state, reducer)`
+      lets you render a temporary state that reverts automatically if
+      the awaiting action rejects. Pair with a Server Action invoked
+      from a form's `action={...}`; React reconciles when the action
+      resolves. Don't reach for useState + manual rollback — the hook
+      handles the rollback.
+    scope: user
+    tags: [react-19, hooks, optimistic-ui]
+    source: 'https://react.dev/reference/react/useOptimistic'
+  - title: 'use(promise) unwraps a promise inside a Server Component'
+    body: |
+      The `use(promise)` hook in React 19 unwraps a Promise inline
+      during render. Inside an `async` Server Component you can `await`
+      directly; inside a Client Component you reach for `use(promise)`
+      so Suspense streams the result. Don't pass an inline
+      `new Promise(...)` — pass a cached promise instance so re-renders
+      don't kick off new fetches.
+    scope: user
+    tags: [react-19, hooks, suspense]
+    source: 'https://react.dev/reference/react/use'
+  - title: 'Hooks at top-level only — never inside loops, conditions, or nested fns'
+    body: |
+      React's Rules of Hooks still apply in React 19: hooks must run
+      at the top level of a function component or another hook, in the
+      same order on every render. Putting useState inside an `if` or a
+      callback breaks React's index-based hook state — silent state
+      corruption that surfaces as "stale state" bugs.
+    scope: user
+    tags: [react-19, hooks, rules-of-hooks]
+    source: 'https://react.dev/reference/rules/rules-of-hooks'
+  - title: 'Server Actions need "use server" — file-level OR function-level'
+    body: |
+      A Server Action is any function with `"use server"` at the top of
+      its source file (every export becomes a Server Action) OR with
+      `"use server"` as the first line INSIDE the function body
+      (function-level opt-in). Don't mix — a file-level "use server"
+      with one local helper that ALSO has "use server" inside is
+      redundant and confuses some bundlers.
+    scope: user
+    tags: [react-19, server-actions, conventions]
+    source: 'https://react.dev/reference/rsc/use-server'
+  - title: 'forwardRef is gone — refs are a normal prop in React 19'
+    body: |
+      React 19 lets you pass `ref` as a regular prop on function
+      components. `forwardRef` still works for back-compat but new
+      components should accept `function MyButton({ref, ...props})`
+      directly. Type the prop as `Ref<HTMLButtonElement>` (or
+      whatever element). One fewer wrapper layer + cleaner devtools.
+    scope: user
+    tags: [react-19, refs, api-changes]
+    source: 'https://react.dev/blog/2024/12/05/react-19'
+
+verify_gates:
+  - name: no-react-18-imports
+    when:
+      event_kind: tool_call
+    # Catch attempts to install/use react-18-only APIs alongside React 19.
+    # React 19 callers that grep for the `react-dom/server` legacy entry
+    # are usually about to ship a Suspense-incompatible SSR path.
+    check: contains(tool_args.command, "react-dom/server")
+    on_fail:
+      level: warn
+      message: |
+        focused-react-19: `react-dom/server` is the legacy SSR entry —
+        React 19 server-rendering goes through `react-dom/server.edge`
+        or the framework's renderer (Next, Remix, etc.). Verify this
+        isn't a stale import path.
+  - name: no-class-component-creation
+    when:
+      event_kind: tool_call
+    # React 19 hooks + Server Components leave class components without a
+    # use case for new code (legacy code can stay). Flag `extends Component`.
+    check: contains(tool_args.content, "extends Component")
+    on_fail:
+      level: warn
+      message: |
+        focused-react-19: Writing a NEW `class extends Component`?
+        React 19 hooks + Server Components handle every case classes
+        do, with simpler state management. Use a function component
+        unless porting legacy code one-to-one.
+  - name: no-default-export-of-server-action
+    when:
+      event_kind: tool_call
+    # A default-exported "use server" function loses its stable name for
+    # the action-id derivation that Next/Remix bundlers use.
+    check: contains(tool_args.content, "export default async function")
+    on_fail:
+      level: warn
+      message: |
+        focused-react-19: Server Actions should be NAMED exports — the
+        action-id derivation in Next/Remix uses the export name to
+        produce stable client→server identifiers. Default-exported
+        async functions cause action-id churn across builds.

package/packs/builtin/focused-typescript-strict/README.md

@@ -0,0 +1,21 @@
+# focused-typescript-strict
+
+Opt-in focused pack encoding TypeScript 5 strict-mode idioms (exhaustiveness
+via `never`, discriminated unions, `as const` narrowing, no-fail-open at
+switches) as a discipline + recall surface for typed codebases.
+
+## Activation
+
+Auto-activates via `detected_by` when `tsconfig.json` exists (broad signal)
+AND optionally when `compilerOptions.strict === true` (narrow signal).
+Opt-in via `active.json`.
+
+## What ships
+
+- **DOG.1 (this commit)**: manifest + foundation + detected_by.
+- **DOG.4**: seed lessons + verify gates.
+
+## See also
+
+- [`docs/pack-runtime.md`](../../../docs/pack-runtime.md) §1.2/§1.3/§1.4.
+- DOG.2 composes this pack into `frontend-react-19-atomic`.

package/packs/builtin/focused-typescript-strict/manifest.yaml

@@ -0,0 +1,163 @@
+# focused-typescript-strict — TypeScript 5 strict-mode idioms.
+#
+# Focused pack — TypeScript with `strict: true` only (intentionally excludes
+# loose-typed JS or non-strict TS). Aggregated into frontend-react-19-atomic
+# (DOG.2).
+name: focused-typescript-strict
+version: 0.1.0
+scope: domain
+goal: Encode TypeScript 5 strict-mode idioms (exhaustiveness via `never`, discriminated unions, `as const` narrowing, no-fail-open at switches) as opt-in discipline + recall surface.
+description: |
+  Focused pack — activates when tsconfig.json has compilerOptions.strict: true.
+  Aggregated into frontend-react-19-atomic composite for the v1 dogfood demo.
+  Skills land in DOG.4.
+
+activation_scope: project
+
+foundation:
+  tools:
+    - name: typescript
+      semver: '>=5'
+  domains:
+    - typed-frontend
+    - typed-backend
+  methodologies:
+    - strict-mode
+    - exhaustiveness
+    - discriminated-unions
+    - no-fail-open
+
+detected_by:
+  # OR semantics — either signal activates the pack.
+  - kind: file_exists
+    path: tsconfig.json
+  - kind: file_match
+    path: tsconfig.json
+    matches:
+      'compilerOptions.strict': '^true$'
+
+# DOG.4 — seed_lessons + verify_gates populated. Lessons cover the
+# strict-mode features most often misused; gates catch the patterns that
+# silently fail-open at runtime.
+seed_lessons:
+  - title: 'Exhaustiveness via assertNever — switch on a discriminated union ends in never'
+    body: |
+      Pattern: union with discriminator `type: 'a' | 'b'` switched in a
+      function. After the cases, assign the variable to a parameter
+      typed `never` and throw — adding a new variant becomes a
+      compile error. Without this, an added variant silently falls
+      through and the function returns undefined.
+
+        type T = {type: 'a'} | {type: 'b'}
+        function f(t: T) {
+          switch (t.type) {
+            case 'a': return 1
+            case 'b': return 2
+            default: const _: never = t; throw new Error(`unhandled: ${t}`)
+          }
+        }
+    scope: user
+    tags: [typescript, exhaustiveness, never]
+    source: 'https://www.typescriptlang.org/docs/handbook/2/narrowing.html#exhaustiveness-checking'
+  - title: 'as const for narrowing array + tuple literals'
+    body: |
+      `[1, 2, 3] as const` becomes `readonly [1, 2, 3]` instead of
+      `number[]`. Critical for routing tables / enum-like arrays where
+      you want each entry's literal type preserved + `typeof arr[number]`
+      to yield the union. Without `as const` you get widened `string[]`
+      and lose the union.
+    scope: user
+    tags: [typescript, as-const, narrowing]
+    source: 'https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions'
+  - title: 'Discriminated unions over option-bag interfaces'
+    body: |
+      Don't model "either this OR that" as a single interface with
+      half-optional fields — every consumer has to defensively check
+      `if (x.a !== undefined)` and the compiler can't help. Use a
+      `kind` discriminator: `{kind: 'a', a: string} | {kind: 'b', b:
+      number}`. The compiler narrows after one `if (x.kind === 'a')`.
+    scope: user
+    tags: [typescript, discriminated-unions, modeling]
+    source: 'https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions'
+  - title: 'noUncheckedIndexedAccess — array[i] is T | undefined'
+    body: |
+      With `noUncheckedIndexedAccess: true`, `arr[5]` yields `T |
+      undefined` even when the array is typed `T[]`. Forces explicit
+      narrowing or `??` default. Pairs with strict-mode to eliminate
+      a major source of silent runtime undefined errors. Enable in
+      every new project; gradually adopt in older ones via narrow
+      const-array patterns.
+    scope: user
+    tags: [typescript, strict-mode, tsconfig]
+    source: 'https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html#noUncheckedIndexedAccess'
+  - title: 'satisfies T preserves the inferred narrow type while validating shape'
+    body: |
+      `const config = {...} satisfies AppConfig` validates `config`
+      against `AppConfig` BUT keeps the inferred literal types so
+      downstream `typeof config.handlers.x` stays the narrow shape.
+      Compare with `const config: AppConfig = {...}` which WIDENS to
+      AppConfig and loses literal narrowing.
+    scope: user
+    tags: [typescript, satisfies, inference]
+    source: 'https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html#the-satisfies-operator'
+  - title: 'No `as` casts to silence the compiler — prefer type guards'
+    body: |
+      `x as Foo` tells the compiler "trust me" with zero runtime check —
+      a silent fail-open. When you genuinely know more than the
+      compiler, write a type guard: `function isFoo(x: unknown): x is
+      Foo { return ... }`. Casts are a last resort for boundaries
+      (JSON.parse, etc.); never in normal control flow.
+    scope: user
+    tags: [typescript, type-safety, anti-pattern]
+    source: 'https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates'
+  - title: 'unknown over any at boundaries (JSON.parse, fetch, env)'
+    body: |
+      `JSON.parse(x)` returns `any` — the compiler stops checking
+      anything you do with the result. Re-type the call site as
+      `unknown` (`const data = JSON.parse(x) as unknown`) and validate
+      the shape (Zod, valibot, manual type guard). `unknown` forces
+      validation; `any` is a hole in the type system.
+    scope: user
+    tags: [typescript, type-safety, boundaries]
+    source: 'https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-unknown-type'
+
+verify_gates:
+  - name: no-any-annotation
+    when:
+      event_kind: tool_call
+    # `: any` is the strict-mode escape hatch the discipline forbids.
+    # tool_args.content is the typical Edit/Write content surface.
+    check: 'contains(tool_args.content, ": any")'
+    on_fail:
+      level: warn
+      message: |
+        focused-typescript-strict: `: any` annotation detected.
+        strict-mode discipline forbids `any` — use `unknown` at
+        boundaries + a type guard, or model the actual type.
+  - name: no-ts-ignore
+    when:
+      event_kind: tool_call
+    # @ts-ignore silently bypasses the compiler — the strict-mode
+    # discipline replaces with @ts-expect-error which fires when the
+    # underlying error is gone (forces cleanup).
+    check: contains(tool_args.content, "@ts-ignore")
+    on_fail:
+      level: warn
+      message: |
+        focused-typescript-strict: `@ts-ignore` detected — prefer
+        `@ts-expect-error` so the suppression FAILS when the
+        underlying type error is gone (forces cleanup).
+  - name: no-bang-non-null-on-array-index
+    when:
+      event_kind: tool_call
+    # arr[i]! claims "definitely not undefined" — silently fail-opens
+    # when noUncheckedIndexedAccess is on. The discipline expects ?? or
+    # explicit narrowing.
+    check: match(tool_args.content, "\\[[0-9]+\\]!")
+    on_fail:
+      level: warn
+      message: |
+        focused-typescript-strict: `arr[N]!` non-null-asserts the
+        index access. Under `noUncheckedIndexedAccess` this loses the
+        runtime-undefined check the type system was providing. Use
+        `?? <default>` or an explicit narrow.

package/packs/builtin/frontend-react-19-atomic/README.md

@@ -0,0 +1,61 @@
+# frontend-react-19-atomic
+
+Composite domain-expert pack for the v0.6 dogfood recipe.
+
+## What it includes
+
+Per `manifest.yaml` `includes:` (MM.1 schema):
+
+- [`focused-react-19`](../focused-react-19/README.md) — React 19+ idioms
+  (Server Components, Actions, useOptimistic, hooks discipline).
+- [`focused-typescript-strict`](../focused-typescript-strict/README.md) —
+  TS 5 strict-mode (exhaustiveness, discriminated unions, no-fail-open).
+- [`focused-atomic-design`](../focused-atomic-design/README.md) — atoms
+  → molecules → organisms layout + token-driven theming.
+
+## Activation
+
+Opt-in via project-scope or user-scope `active.json`:
+
+```json
+{ "packs": ["frontend-react-19-atomic"] }
+```
+
+The composite_resolver (`src/packs/composite_resolver.ts`) expands the
+composite at session-start (IDF.3 caching contract) into a flat list
+containing the composite + its three children. Each child then runs its
+own `detected_by` rules independently — the composite itself carries no
+`detected_by` (children handle gating).
+
+## What ships at this slice (DOG.2)
+
+- `manifest.yaml` — `kind: composite` + 3-entry `includes:` array.
+- `README.md` (this file).
+- Integration tests at `test/builtin/composite-frontend.test.ts` covering
+  load + expansion + child-detection round-trip.
+- NO `foundation:` (composites MUST NOT declare own foundation — pure
+  aggregator per v0.6 §4.7).
+- NO `skills/` directory (composites carry no own skills).
+- NO `models.yaml` (children declare their own model aliases if any).
+
+## What lands later
+
+- **DOG.3** — `seed_lessons` + `verify_gates` schema sugar for focused
+  child packs.
+- **DOG.4** — populate each child's `skills/` + 5–10 seed lessons + 2–3
+  verify gates per pack.
+- **DOG.5** — living-pack version ledger integration for the composite
+  (auto-merge on upgrade flow).
+- **DOG.6** — execute the 9-step dogfood recipe end-to-end on a real
+  React 19 project.
+
+## Composite-pack rules (from pack-runtime.md §1.7)
+
+| Field           | Composite (`kind: composite`) requirement                              |
+| --------------- | ---------------------------------------------------------------------- |
+| `includes`      | **REQUIRED** non-empty array of `{pack_id, semver}` entries            |
+| `foundation`    | **FORBIDDEN** — composite is a pure aggregator                         |
+| `detected_by`   | OPTIONAL — additional gate WHEN to expand includes                     |
+| `skills/` dir   | typically empty — children contribute skills                           |
+| Depth cap       | 3 levels of nested composite expansion (composite-of-composites)       |
+| Cycle detection | per-root visited-set — cycle → `CompositeResolutionError` at load time |

package/packs/builtin/frontend-react-19-atomic/manifest.yaml

@@ -0,0 +1,124 @@
+# frontend-react-19-atomic — v1 dogfood COMPOSITE pack.
+#
+# Composite (kind: composite per MM.1) — pure aggregator that includes
+# the three DOG.1 focused packs. Per pack-runtime.md §1.7:
+#   - composite MUST NOT declare its own `foundation:` (validation rule)
+#   - composite MAY declare its own `detected_by` (an additional gate WHEN
+#     to expand includes) — omitted here because the children already
+#     auto-activate via their own detected_by rules; no benefit from
+#     duplicating the gating at composite level.
+#   - composite_resolver (src/packs/composite_resolver.ts) walks
+#     `includes:` at discovery time and inlines the matched focused packs
+#     into the expanded registry; depth-cap 3 levels; cycle-detection on.
+#
+# This pack is the user-facing handle for the v0.6 9-step dogfood demo
+# (T-PRODUCT-COMPLETION pre-research §4). A user installs THIS pack;
+# the runtime auto-expands to focused-react-19 + focused-typescript-strict
+# + focused-atomic-design. Each child's detected_by fires independently
+# against the project's filesystem signals.
+name: frontend-react-19-atomic
+version: 0.1.0
+scope: domain
+kind: composite
+goal: Composite domain-expert pack — aggregates focused-react-19 + focused-typescript-strict + focused-atomic-design. Validates the v0.6 composite recipe end-to-end via the 9-step ship demo (T-PRODUCT-COMPLETION pre-research §4).
+description: |
+  Per pack-runtime.md §1.7 + v0.6 design §3 — composite packs declare
+  `kind: composite` + an `includes:` list of {pack_id, semver} entries.
+  At load time the composite_resolver walks the registry, validates each
+  semver range against the discovered focused pack's version, and inlines
+  the children into the expanded pack list. Each focused child's
+  detected_by, foundation, activation_scope, and skills remain owned by
+  the child — the composite is purely a named handle for the
+  three-pack assembly.
+
+  Personal-dogfood usage: opt in via `~/.opensquid/active.json`:
+    { "packs": ["frontend-react-19-atomic"] }
+  Composite expansion happens at session-start (IDF.3 caching contract).
+
+activation_scope: project
+
+includes:
+  - pack_id: focused-react-19
+    semver: '>=0.1.0'
+  - pack_id: focused-typescript-strict
+    semver: '>=0.1.0'
+  - pack_id: focused-atomic-design
+    semver: '>=0.1.0'
+
+# No `foundation:` — composites are pure aggregators per v0.6 §4.7
+# (manifest.ts validation rule at line ~439).
+#
+# No `detected_by:` — child packs each auto-activate via their own
+# detected_by rules; redundant composite-level gating would add no
+# signal value and complicate auditability.
+#
+# No `skills/` directory — composites carry no own skills; children
+# contribute their own skills which flatten into the runtime registry
+# via composite_resolver expansion.
+
+# DOG.4 — composite-level cross-domain seed_lessons. Composites CAN
+# declare seed_lessons even though they cannot declare foundation —
+# the seeds aggregate the three domains into rules that need ALL three
+# at once (React 19 + TS strict + Atomic Design).
+seed_lessons:
+  - title: 'Atomic React 19 atom: strict-typed props, ref-as-prop, no client state'
+    body: |
+      A React 19 atom in an atomic-design system: typed prop interface
+      (no `any`), accepts `ref` as a normal prop (no forwardRef in new
+      code), renders pure JSX (no `useState`, no client APIs at this
+      level). Pattern:
+
+        type ButtonProps = {
+          ref?: Ref<HTMLButtonElement>
+          variant: 'primary' | 'ghost'
+          children: ReactNode
+        }
+        export function Button({ref, variant, children}: ButtonProps) {
+          return <button ref={ref} className={...}>{children}</button>
+        }
+
+      Discriminated `variant` union narrows downstream consumers.
+    scope: user
+    tags: [composite, react-19, typescript, atomic-design]
+    source: 'https://react.dev/blog/2024/12/05/react-19#ref-as-a-prop'
+  - title: 'Server Components + token-driven theming: theme tokens are server-rendered too'
+    body: |
+      Token CSS variables (`var(--color-primary)`) render correctly in
+      Server Components because they live in the static stylesheet,
+      not the client bundle. No "use client" needed to switch themes
+      via CSS-only mechanisms. Reserve "use client" for components
+      that read the theme value via JS (rare; usually a code smell —
+      can the styling do it instead?).
+    scope: user
+    tags: [composite, react-19, atomic-design, tokens]
+  - title: 'Page-level Server Action with strict-typed FormData parsing'
+    body: |
+      Pages (the data-binding level in atomic design) own Server
+      Actions. Strict-mode TS forces FormData unwrapping through a
+      validator (Zod/valibot) before consumption:
+
+        export async function createPost(formData: FormData) {
+          'use server'
+          const parsed = postSchema.safeParse({
+            title: formData.get('title'),
+            body: formData.get('body'),
+          })
+          if (!parsed.success) return {error: parsed.error.flatten()}
+          // parsed.data is now strict-typed
+        }
+
+      Combines the React 19 Server Action surface + TS exhaustiveness
+      + atomic-design page-level data-binding boundary.
+    scope: user
+    tags: [composite, server-actions, validation, page-level]
+    source: 'https://react.dev/reference/rsc/use-server'
+  - title: 'Storybook stories for atoms cite the design-token + TS-strict guarantees'
+    body: |
+      An atom's Storybook story should demonstrate (a) variant
+      coverage (every discriminated `variant` value renders), (b)
+      token theming (light/dark/brand variants via CSS-var swap), (c)
+      no runtime errors with `noUncheckedIndexedAccess` strict-mode
+      enabled. The composite recipe makes this routine because all
+      three packs are loaded together.
+    scope: user
+    tags: [composite, storybook, design-system, testing]

package/packs/builtin/general/chat_agent.yaml

@@ -0,0 +1,16 @@
+# general — chat-agent binding (T-CHAT-AS-TERMINAL CAT.6).
+#
+# Model-aliased: resolves the `fast_chat` alias from the user's models.yaml
+# (NO hardcoded model id — portability per invariant #10). The same alias the
+# WAB.6 fallback + setup wizard use.
+#
+# PROJECT-LESS: the general session has NO project memory by design, so the two
+# project-memory built-ins are disabled here — `recall` (project RAG lookup) and
+# `store_lesson` (project lesson buffer) would both reach into project-scoped
+# state. Only `chat_send` (reply to the user) remains. This is the structural
+# guarantee that the general session can't leak/accumulate project context.
+default_model: fast_chat
+system_prompt: system_prompt.md
+disable_builtins:
+  - recall
+  - store_lesson

package/packs/builtin/general/manifest.yaml

@@ -0,0 +1,39 @@
+# general — the project-LESS general chat assistant (T-CHAT-AS-TERMINAL CAT.6).
+#
+# Per the opensquid thesis (agent = its pack), the general chat session runs as
+# this dedicated lightweight pack. It owns the Telegram DM + the supergroup
+# "General" thread + the "All" topic — all routed to the umbrella `general`
+# (channels.json: `general.telegram` with dm_user_ids + owns_general_thread).
+#
+# Project-LESS BY DESIGN: this pack declares NO project drift gates, NO
+# detected_by activation (it is launched explicitly for umbrella=general, never
+# auto-activated into a project session), and the chat agent is bound WITHOUT
+# the project-memory tools (recall / store_lesson are disabled in
+# chat_agent.yaml). The general session must never leak project context.
+#
+# Model-aliased (no hardcoded model id): the chat agent resolves the
+# `fast_chat` alias from the user's models.yaml — portability preserved per
+# [[project_opensquid_model_neutral_subagent_primitive]] + invariant #10.
+#
+# Launched via `opensquid agent-bridge run-foreground --general` (CLI) which
+# resolves umbrella=general, loads this pack, and runs the daemon project-less
+# (umbrella id is the scope identity; no project uuid).
+name: general
+version: 0.1.0
+scope: universal
+kind: focused
+goal: answer the general project-less chat — DM + General thread + All topic — with no project context
+description: |
+  The project-less general chat assistant. Owns the Telegram DM, the supergroup
+  General thread, and the "All" topic (umbrella=general). It is a plain helpful
+  assistant: it answers general questions and routes nothing to a project topic.
+
+  No project memory by design — the bound chat agent (chat_agent.yaml) disables
+  the recall + store_lesson tools, leaving only chat_send. No drift gates, no
+  skills: the general session is deliberately minimal so no project discipline
+  or project context bleeds into it.
+# Not auto-loaded into any project session — launched explicitly for the
+# general umbrella. Empty detected_by = no filesystem/conversation auto-activation
+# trigger fires this pack into a project agent.
+detected_by: []
+evolves: false

package/packs/builtin/general/system_prompt.md

@@ -0,0 +1,11 @@
+You are the general assistant in opensquid's chat. You serve the Telegram DM,
+the supergroup "General" thread, and the "All" topic — none of which belong to
+any project.
+
+You have NO project context and NO project memory by design. Do not reference,
+assume, or fabricate project state, files, repositories, or prior project work.
+If a request is clearly about a specific project, say it belongs in that
+project's own chat topic rather than here.
+
+Reply concisely and helpfully. Use the `chat_send` tool to deliver your final
+answer to the user.