@synap-core/workspace-templates 0.12.0 → 0.24.0

package/src/builder.yaml

@@ -16,16 +16,44 @@
 meta:
   slug: builder-workspace
   domain: build
-  name: Builder
-  description: "Builder workspace — apps, features, services, packages, environments, deployments, recipes, decisions, incidents, plus delegated agent tasks/projects/skills/providers."
+  name: Dev
+  description: "Dev workspace — apps, features, services, packages, environments, deployments, recipes, decisions, incidents, plus delegated agent tasks/skills/providers."
   icon: wrench
   color: "#7C3AED"
   tags: [builder, developer, agents]
   isPublic: true
+  # Onboarding start (meta.start): the "product and dev" card.
+  start:
+    order: 1
+    label: Product and dev
+    promise: Everything your agents are building, from backlog to done.
+    suggestFor: [developer]
+    profile: task
+    views: [task-board]
+    example:
+      - { title: "Add Stripe checkout", values: { task-status: Running, task-priority: High, task-type: Code } }
+      - { title: "Research competitor pricing", values: { task-status: Queued, task-priority: Medium, task-type: Research } }
+      - { title: "Fix login redirect loop", values: { task-status: Review, task-priority: Critical, task-type: Code } }
+      - { title: "Write the launch changelog", values: { task-status: Backlog, task-priority: Low, task-type: Content } }
+      - { title: "Ship v0.2 to staging", values: { task-status: Done, task-priority: High, task-type: Ops } }
+    firstSession:
+      title: Your live tasks
+      goal: "Add the 3 to 5 pieces of product work you or your agents are doing now, each with a status and a priority."
+    starters:
+      - "I am building a SaaS app with a small team"
+      - "I want my coding agents to pick up tasks from a board"
+      - "I am shipping a side project on weekends"
+  # What this space PRODUCES (homes): the purpose word, then its kinds/roles.
+  intent:
+    label: Product
+    produces:
+      - profile: devplane_feature
+      - profile: devplane_story
+      - profile: ui-design
 
 workspace:
-  name: Builder
-  description: "Developer + agent intelligence layer. Combines the DevPlane developer schema (apps, packages, services, environments, deployments, recipes, decisions, incidents) with the OpenClaw delegation primitives (project, task, skill, provider). Agents are pod-level identities — not tracked as workspace entities."
+  name: Dev
+  description: "Developer + agent intelligence layer. Combines the DevPlane developer schema (apps, packages, services, environments, deployments, recipes, decisions, incidents) with the agent delegation primitives (task, skill, provider). Agents are pod-level identities — not tracked as workspace entities."
   proposalId: builder-workspace-v1
   subtype: builder
   visibility: pod_visible
@@ -104,17 +132,38 @@ profiles:
     icon: git-branch
     color: blue
     description: A feature or work item with a persistent AI session
+    # The feature's ONE lifecycle (founder, 2026-10-13). The stored keys stay
+    # the ones live pods already hold; the labels carry the decided words.
+    # `agent_status` is the agent pipeline's runtime bookkeeping, not a lifecycle.
+    lifecycle:
+      property: featureStatus
+      options:
+        - { key: backlog, label: Idea, category: open }
+        - { key: spec, label: Spec, category: active }
+        - { key: in_progress, label: Building, category: active }
+        - { key: in_review, label: Review, category: active }
+        - { key: done, label: Shipped, category: done }
+        - { key: cancelled, label: Dropped, category: lost, humanOnly: true }
     properties:
       - slug: featureStatus
         label: Status
         valueType: string
         inputType: select
-        enumValues: [backlog, in_progress, in_review, done, cancelled]
+        enumValues: [backlog, spec, in_progress, in_review, done, cancelled]
       - slug: priority
         label: Priority
         valueType: string
         inputType: select
         enumValues: [low, medium, high, critical]
+      # The work type of a feature (founder decision 2 A, 2026-10-26): a
+      # session's type is its subject's kind, and this one field splits the
+      # Feature kind. Bugs are `issue`, designs `ui-design`: never values here.
+      # No default: an unset value is "not typed yet", not "feature".
+      - slug: change
+        label: Change
+        valueType: string
+        inputType: select
+        enumValues: [feature, refactor, chore]
       - slug: linkedApp
         label: Linked App
         valueType: string
@@ -204,12 +253,23 @@ profiles:
     icon: book-marked
     color: violet
     description: A user-facing story that orchestrates features and drives the AI pipeline
+    # The story's ONE lifecycle (founder, 2026-10-13). Keys live pods hold are
+    # kept; `in-review` is not a story stage any more (its feature carries the
+    # review). `agent_status` is runtime bookkeeping, not a lifecycle.
+    lifecycle:
+      property: storyStatus
+      options:
+        - { key: backlog, label: Draft, category: open }
+        - { key: ready, label: Ready, category: active }
+        - { key: in-progress, label: In feature, category: active }
+        - { key: done, label: Done, category: done }
+        - { key: dropped, label: Dropped, category: lost, humanOnly: true }
     properties:
       - slug: storyStatus
         label: Status
         valueType: string
         inputType: select
-        enumValues: [backlog, in-progress, in-review, done]
+        enumValues: [backlog, ready, in-progress, done, dropped]
         constraints: { defaultValue: backlog }
       - slug: priority
         label: Priority
@@ -917,60 +977,6 @@ profiles:
         valueType: date
         inputType: date
 
-  - slug: project
-    displayName: Project
-    icon: folder
-    color: "#2E6DA4"
-    description: A bounded body of work delegated to one or more agents
-    properties:
-      - slug: project-status
-        label: Status
-        valueType: string
-        inputType: select
-        enumValues:
-          [Backlog, Queued, In Progress, Blocked, Completed, Cancelled]
-      - slug: project-priority
-        label: Priority
-        valueType: string
-        inputType: select
-        enumValues: [Critical, High, Medium, Low]
-      - slug: project-owner
-        label: Human Owner
-        valueType: entity_id
-        targetProfileSlug: person
-      - slug: project-start
-        label: Start Date
-        valueType: date
-      - slug: project-deadline
-        label: Deadline
-        valueType: date
-      - slug: project-health
-        label: Health
-        valueType: string
-        inputType: select
-        enumValues: [Green, Yellow, Red]
-      - slug: project-type
-        label: Type
-        valueType: string
-        inputType: select
-        enumValues:
-          [
-            Development,
-            Research,
-            Content,
-            Automation,
-            DevOps,
-            Data,
-            Outreach,
-            Monitoring,
-          ]
-      - slug: project-goal
-        label: Goal
-        valueType: string
-      - slug: project-outcome
-        label: Expected Outcome
-        valueType: string
-
   - slug: task
     displayName: Task
     icon: check-square
@@ -989,10 +995,6 @@ profiles:
         inputType: select
         enumValues: [Critical, High, Medium, Low]
         constraints: { defaultValue: Medium }
-      - slug: task-project
-        label: Project
-        valueType: entity_id
-        targetProfileSlug: project
       - slug: task-type
         label: Type
         valueType: string
@@ -1291,6 +1293,117 @@ profiles:
         valueType: string
         inputType: text
 
+  # A screen designed from REAL components (DESIGN-DEV-XP-PLAN P6). The design
+  # is Puck JSON whose every `type` is a component the Storybook manifest
+  # (`/manifests/components.json`) lists — never an invented one. The pod is
+  # where the design lives; the canvas edits it; a coding agent implements it.
+  # Skill: designing-with-real-components (+ design-critique for the rubric).
+  # Process: "Design to implementation". A request yields 3 VARIANTS: sibling
+  # ui-designs sharing one `variant-group`. References (the founder's own
+  # captures, files) are linked with the base `references` relation — never a
+  # property.
+  - slug: ui-design
+    displayName: UI Design
+    icon: layout-template
+    color: violet
+    description: A screen designed from the real component library — Puck JSON a person reviews on the canvas and a coding agent implements.
+    # The ONE lifecycle (work model L1). `approved` (the design review) and
+    # `archived` are a person's call only.
+    lifecycle:
+      property: design-status
+      options:
+        - { key: draft, category: open }
+        - { key: in-review, category: active }
+        - { key: approved, category: active, humanOnly: true }
+        - { key: implementing, category: active }
+        - { key: implemented, category: done }
+        - { key: archived, category: lost, humanOnly: true }
+    # How it renders (entity rendering, decision 8): @synap-core/types/presentation.
+    presentation:
+      family: media
+      media:
+        source: { entityRef: screenshot }
+        kind: image
+    properties:
+      - slug: design-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [draft, in-review, approved, implementing, implemented, archived]
+        constraints: { defaultValue: draft }
+      - slug: target-surface
+        label: Target surface
+        valueType: string
+        inputType: text
+        placeholder: "The app and screen it is for, e.g. browser › Settings › Agents"
+      - slug: design-scope
+        label: Scope
+        description: One component, or a whole page.
+        valueType: string
+        inputType: select
+        enumValues: [component, page]
+        constraints: { defaultValue: page }
+      - slug: design-goal
+        label: Goal
+        description: The job the screen does for its reader, in one or two sentences — what the critique judges it against.
+        valueType: string
+        inputType: textarea
+      - slug: variant-group
+        label: Variant group
+        description: One id shared by the sibling variants of one design request, so they are compared side by side.
+        valueType: string
+        inputType: text
+      - slug: current-story-id
+        label: Current story
+        description: The Storybook story id of the screen as it is today, when it exists — the "before" of the compare.
+        valueType: string
+        inputType: text
+      - slug: design-json
+        label: Design (Puck JSON)
+        description: "Puck data: content[] of { type, props: { id, … } }, root.props, zones. Every type is a component in the Storybook manifest."
+        valueType: json
+        inputType: json
+      - slug: components-used
+        label: Components used
+        description: The component names the design JSON uses — filled from the JSON, never by hand.
+        valueType: array
+        inputType: text
+      - slug: schema-version
+        label: Schema version
+        description: Version of the design JSON shape, for migrations.
+        valueType: number
+        inputType: number
+        constraints: { defaultValue: 1 }
+      - slug: screenshot
+        label: Screenshot
+        valueType: entity_id
+        targetProfileSlug: file
+        inputType: entity_select
+        description: A render of the design, for review at a glance.
+      - slug: motion
+        label: Motion
+        description: "The design's motion: a list of { trigger, target, preset } where preset is a named motion preset of the design tokens (each carries its reduced-motion fallback)."
+        valueType: json
+        inputType: json
+      - slug: critique
+        label: Critique
+        description: "The latest critique findings (skill design-critique): a list of { id, tier, rule, severity, confidence, region, evidence, suggestion?, verdict? }."
+        valueType: json
+        inputType: json
+      - slug: implementation-pr
+        label: Implementation PR
+        valueType: string
+        inputType: url
+      - slug: implemented-story-id
+        label: Implemented story
+        description: The Storybook story id of the built screen — the "after" of the compare.
+        valueType: string
+        inputType: text
+      - slug: design-notes
+        label: Notes
+        valueType: string
+        inputType: textarea
+
 views:
   - name: Apps
     type: table
@@ -1298,6 +1411,7 @@ views:
     config:
       columns: [title, appStatus, techStack, port, deployUrl]
   - name: Task Board
+    slug: task-board
     type: kanban
     scopeProfileSlug: task
     groupBy: task-status
@@ -1321,11 +1435,41 @@ views:
     scopeProfileSlug: devplane_incident
     config:
       columns: [title, severity, incidentStatus, affectedApps, resolvedAt]
-  - name: Projects
+  # ── Folded from the retired dev-dashboard template (R7, 2026-09-27) ───────
+  # Rebuilt over THIS template's own kinds (devplane_service /
+  # devplane_deployment / provider). Never port dev-dashboard's `credential`
+  # kind (secrets are not entities), its `vendor`/`repository` twins, or its
+  # dev-* widgets (no implementation ever existed).
+  - name: Service Health
+    slug: service-health
+    type: kanban
+    scopeProfileSlug: devplane_service
+    groupBy: serviceStatus
+    description: Every service by health — healthy, degraded, down, maintenance.
+  - name: Services by Type
+    slug: services-by-type
     type: kanban
-    scopeProfileSlug: project
-    groupBy: project-status
-    description: Delegated projects by status.
+    scopeProfileSlug: devplane_service
+    groupBy: serviceType
+    description: Services grouped by what they are — API, worker, cron, database, cache, queue.
+  - name: Deploy Timeline
+    slug: deploy-timeline
+    type: table
+    scopeProfileSlug: devplane_deployment
+    sortBy: deployedAt
+    sortOrder: desc
+    config:
+      columns: [title, deployStatus, version, linkedApp, linkedEnvironment, deployedBy, deployedAt]
+    description: Most recent deployments first — what shipped, where, and whether it held.
+  - name: Provider Costs
+    slug: provider-costs
+    type: table
+    scopeProfileSlug: provider
+    sortBy: provider-spend-week
+    sortOrder: desc
+    config:
+      columns: [title, provider-type, provider-spend-week, provider-budget-day, provider-cost-input, provider-cost-output, provider-key-health]
+    description: What each provider costs — this week's spend against the daily ceiling, highest first.
   # ── Architecture graph (ReactFlow) ───────────────────────────────────────
   # These views are MULTI-PROFILE on purpose: a flow that only loaded one
   # profile would have nodes but no edges (its relations point at OTHER types).
@@ -1401,6 +1545,547 @@ playbooks:
     executor: is-agent
     status: active
 
+  # THE PROCESS on `ui-design` (DESIGN-DEV-XP-PLAN P6). It FOLLOWS the
+  # lifecycle the profile declares (`design-status`); it never keeps a second
+  # status. `approved` is humanOnly: a person sets it on the canvas, so no
+  # stage owns it. Generate writes 3 sibling VARIANTS (one variant-group);
+  # Critique (no status, like Verify) judges them against the design-critique
+  # rubric and a blocker loops to Generate. The Review gate is the commitment:
+  # nothing is implemented from a design a person has not approved; a
+  # rejection loops to Generate. Verify's check gate and Done's human gate both
+  # send rework to Implement.
+  # The worker is MANUAL: Generate creates the sibling variants as ui-designs,
+  # and an `on: created` worker would propose a run for each of them (the
+  # activator grammar has no filter to tell a request from a variant).
+  - name: Design to implementation
+    description: Take a UI design request from three variants built only of real Storybook components, through a rubric critique and a person's review on the canvas, to a pull request verified by the gates, a before/after compare and a walk in the running app.
+    goalTemplate: >-
+      Take this UI design ({design}) for {surface} from draft to implemented.
+      Load the designing-with-real-components skill first, and design-critique
+      for the Critique stage. GENERATE: read the Storybook component manifest
+      (/manifests/components.json, or the Storybook MCP), the design's goal and
+      scope and the entities it references, and write THREE variants as Puck
+      JSON — this design and two sibling ui-designs sharing its variant-group —
+      using ONLY components the manifest lists, with props each one declares,
+      design tokens and named motion presets only; each variant lays out every
+      state the screen has (empty, loading, failed, full, long content); fill
+      components-used from the JSON and set schema-version. CRITIQUE: judge each
+      variant with the design-critique rubric and write the findings into its
+      critique; a checked or pattern blocker sends the run back to Generate;
+      opinions are never applied. REVIEW: a person compares the variants on the
+      canvas and approves one; nothing is implemented from an unapproved design,
+      and only a person sets approved. IMPLEMENT: read design-json and the
+      Storybook MCP, build the screen from those same real components, open a
+      pull request and record its URL in implementation-pr and the built
+      screen's story in implemented-story-id. VERIFY: typecheck, story coverage,
+      interaction and accessibility tests, visual regression and the token
+      guards are green, the implemented story was captured and compared with
+      the design and the current story, and the screen was walked in the
+      running app. Move the design's status only through its lifecycle
+      (update_entity with expectedStatus); never invent a status.
+    subjectProfile:
+      profileSlug: ui-design
+      statusProperty: design-status
+    # No stage owns these: `approved` and `archived` are a person's call
+    # (humanOnly on the lifecycle).
+    humanOnlyStatuses: [approved, archived]
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: design, type: entity, label: UI design, required: true }
+      - { name: surface, type: text, label: Target surface }
+    executor: is-agent
+    status: active
+    stages:
+      - key: generate
+        name: Generate
+        category: planned
+        subjectStatus: draft
+        goal: Write three variants as Puck JSON — this design and two siblings in its variant-group — from components the Storybook manifest lists, with their declared props, tokens and named motion presets only, each with every state the screen has.
+        expectedOutputs:
+          - kind: ui-design
+            label: Sibling variants (same variant-group)
+            relationToSubject: relates_to
+        criteria:
+          - key: design-json-written
+            statement: The design's Puck JSON is saved on the design.
+            check: { kind: evidence, evidenceKey: design-json }
+          - key: design-variants-grouped
+            statement: Three variants exist — this design and two sibling ui-designs in the same variant-group — each with its own design JSON laying out every state the screen has among empty, loading, failed, full and long content.
+            check: { kind: judge }
+          - key: design-real-components-only
+            statement: Every component type in each variant's design JSON is in the Storybook manifest and uses only props it declares, and components-used lists exactly those types.
+            check: { kind: judge }
+      - key: critique
+        name: Critique
+        category: started
+        goal: Judge every variant with the design-critique rubric and write its findings into the variant's critique; a checked or pattern blocker sends the run back to Generate.
+        gate: { kind: check }
+        onFail: { toStage: generate }
+        expectedOutputs:
+          - kind: document
+            label: Design critique (findings by variant, tier and rule id)
+            relationToSubject: relates_to
+        criteria:
+          - key: critique-written
+            statement: Each variant's critique holds its findings, each with a rule id of the design-critique rubric, a tier, a severity and a region.
+            check: { kind: evidence, evidenceKey: critique }
+          - key: critique-no-open-blocker
+            statement: No checked or pattern finding of severity blocker is left open on the variants going to review.
+            check: { kind: judge }
+          - key: critique-opinions-not-applied
+            statement: Every opinion finding names a heuristic id and a region, has low confidence, and was not applied to the design.
+            check: { kind: judge }
+      - key: review
+        name: Review
+        category: started
+        subjectStatus: in-review
+        goal: A person compares the variants and their critiques on the canvas and approves one, or sends the design back with what to change. A sibling chosen over this design is written into it first, so the run carries the chosen variant.
+        # The commitment: implementation starts only from an approved design.
+        gate: { kind: human }
+        onFail: { toStage: generate }
+      - key: implement
+        name: Implement
+        category: started
+        subjectStatus: implementing
+        goal: Build the screen from the approved design JSON with the real components, open a pull request and record it and the built screen's story on the design.
+        criteria:
+          - key: implementation-pr-linked
+            statement: The pull request URL is recorded in implementation-pr.
+            check: { kind: evidence, evidenceKey: implementation-pr }
+          - key: implemented-story-linked
+            statement: The Storybook story id of the built screen is recorded in implemented-story-id.
+            check: { kind: evidence, evidenceKey: implemented-story-id }
+          - key: implementation-matches-design
+            statement: The screen uses the components and structure the design JSON names, with no invented component and no hardcoded colour.
+            check: { kind: judge }
+      - key: verify
+        name: Verify
+        category: started
+        goal: Run the gates, capture the implemented story and compare it with the design (and the current story when there is one), and walk the screen in the running app; write what passed and what failed.
+        gate: { kind: check }
+        onFail: { toStage: implement }
+        expectedOutputs:
+          - kind: document
+            label: Verification report (gates, compare and dogfood walk)
+            relationToSubject: relates_to
+        criteria:
+          - key: verify-gates-green
+            statement: Typecheck, story coverage, interaction, accessibility, visual regression and the token guards are green on the pull request.
+            check: { kind: judge }
+          - key: verify-compare
+            statement: The implemented story was captured and compared with the design, and the report names every difference.
+            check: { kind: judge }
+          - key: verify-dogfood-walk
+            statement: The screen was walked in the running app and the report carries what was seen.
+            check: { kind: judge }
+      - key: done
+        name: Done
+        category: completed
+        subjectStatus: implemented
+        goal: A person confirms the pull request merged and the screen matches the approved design; approving writes implemented.
+        # A HUMAN gate (as Content OS Publish): a check gate judges the stage
+        # being LEFT, so it would write implemented before anyone saw the merge.
+        gate: { kind: human }
+        onFail: { toStage: implement }
+
+  # THE APP FACTORY (2026-10-21): "let's build app X" → a designed, verified,
+  # built app, the person asked at THREE gates only (decisions, design
+  # approval, first look after slice 1). Generalises the Content Studio run of
+  # 2026-10-20 (plan doc 6f728471); the method lives in four skills
+  # (app-factory-research, -design-canvas, -design-review, -build-slice) and
+  # the Website Factory's design-kit/.
+  #
+  # SUBJECT: the app (`devplane_app`), READ, not moved. That kind declares no
+  # `lifecycle:` block, and the catalog's rule is that a kind a playbook moves
+  # declares the moved property as its lifecycle (lifecycle-declarations
+  # test). Its select `appStatus` (planning · active · deprecated · archived)
+  # is therefore left to the person, and no stage carries a subjectStatus.
+  # Consequence: a per-stage worker (`enters_status`) has nothing to fire on,
+  # so the one worker is MANUAL. Making the factory's phases visible on the
+  # Apps board, and giving each stage its own worker, needs a declared
+  # lifecycle on devplane_app with an option per phase — a kind change for
+  # the founder to decide, not invented here.
+  - name: Build an app (App Factory)
+    description: Turn "let's build app X" into a researched, designed, reviewed and verified app, built from the Website Factory in slices. The person is asked only three times — the decisions, the design approval, and a first look after slice 1.
+    goalTemplate: >-
+      Build the app "{name}": {idea}. Path: {path}. Work it as the App
+      Factory, loading each stage's skill with synap_load_skill. INTAKE: find
+      or create the app (resolve first; one devplane_app, never a twin), make
+      it this session's subject, and record the idea in the person's words.
+      RESEARCH (app-factory-research): name-collision check, a data contract
+      per screen with live examples and counts, an identity and permission
+      table (who writes, who approves, can the app's credential do it, with
+      evidence), every platform gap with an id and an owner, and the real
+      sample world; write the plan document. DECISIONS: ask the person 2-4
+      multiple-choice questions in ONE ask, each with a recommended default;
+      nothing is designed before they answer. DESIGN (app-factory-design-canvas):
+      create the app repo from the Website Factory, draw every page and every
+      state, desktop and phone, with its design-kit in the real components and
+      the person's real data, and publish the canvas. REVIEW
+      (app-factory-design-review): run the three read-only lenses in parallel —
+      UX surface, component fidelity + contrast + responsive, data contract per
+      element. CONSOLIDATE: one writer merges them into a redesign brief,
+      applies it, and re-runs design:check and design:preview. DESIGN APPROVAL:
+      the person approves the canvas; nothing is built from boards they have
+      not approved. INFRA: open the platform, catalog and factory pull
+      requests the slices need, each gap with its owner, or label a bridge in
+      the UI and the code. BUILD (app-factory-build-slice): slice by slice,
+      server-only credentials, no writes until the person can sign in, the
+      Website Factory gates re-run independently on the devbox; after slice 1
+      STOP for the person's first look. DOGFOOD: walk the app as the person
+      would and collect their verdict. Branches and pull requests only: never
+      push to main, never publish the catalog, never deploy production.
+      Separate VERIFIED (gate output quoted) from NEEDS-DOGFOOD in every
+      report.
+    subjectProfile:
+      profileSlug: devplane_app
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: name, type: text, label: App name, required: true }
+      - { name: idea, type: text, label: "What should it do, for whom, and what is hard today (in your words)?", required: true }
+      - name: path
+        type: choice
+        label: "Who uses it: the owner over their own pod (private) · visitors with their own pod (pod-app) · the public, showing one pod's published data (showcase) · the public, no pod data (static)"
+        default: private
+        options: [private, pod-app, showcase, static]
+      - { name: app, type: entity, label: The app, if it already exists }
+    executor: is-agent
+    status: active
+    criteria:
+      - key: three-gates-only
+        statement: The person was asked only at the three gates (decisions, design approval, first look), each time in one message with a recommended default.
+        check: { kind: judge }
+      - key: real-sample-world
+        statement: Every board and every built page shows the person's real data; no words are attributed to the person that they did not write.
+        check: { kind: judge }
+      - key: gates-independently-verified
+        statement: Every gate claimed in a report (design:check, design:preview, pnpm verify, pnpm shots, the credential and mutation greps) was re-run by the orchestrator and its output quoted.
+        check: { kind: judge }
+    stages:
+      - key: intake
+        name: Intake
+        category: planned
+        goal: Find or create the app (resolve first), make it the session's subject, and write the idea, the problem, the goal and the measure of success in the person's words.
+        criteria:
+          - key: intake-subject-set
+            statement: The session's subject is the app (one devplane_app, found before created).
+            check: { kind: judge }
+          - key: intake-own-words
+            statement: The problem and the goal are quoted in the person's words, with what is not in v1.
+            check: { kind: judge }
+      - key: research
+        name: Research
+        category: planned
+        goal: Name-collision check, data contract per screen with live counts, identity and permission table, platform gaps with owners, the real sample world, and the plan document (app-factory-research).
+        expectedOutputs:
+          - kind: document
+            label: Plan (problem, decisions, facts verified, pages, slices, gaps register)
+            relationToSubject: relates_to
+          - kind: document
+            label: Data contract per screen and identity table
+            relationToSubject: relates_to
+        criteria:
+          - key: research-contract-live
+            statement: Every screen has data-contract rows with a live example and count, and every action has an identity row with evidence (a live call or file:line).
+            check: { kind: judge }
+          - key: research-gaps-owned
+            statement: Every platform gap has an id, an owner and the slice it blocks.
+            check: { kind: judge }
+      - key: decisions
+        name: Decisions
+        category: planned
+        goal: Ask the person 2-4 multiple-choice questions in one ask, each with a recommended default and its cost; record each answer as a decision on the app.
+        # Gate 1 of 3: nothing is designed before the person answers.
+        gate: { kind: human }
+        onFail: { toStage: research }
+        expectedOutputs:
+          - kind: devplane_decision_record
+            label: One decision per answered question
+            relationToSubject: relates_to
+      - key: design
+        name: Design
+        category: started
+        goal: Create the app repo from the Website Factory and draw every page and every state, desktop and phone, with its design-kit in the real components and the person's real data; publish the canvas (app-factory-design-canvas).
+        expectedOutputs:
+          - kind: document
+            label: Design canvas (link) and board list
+            relationToSubject: relates_to
+        criteria:
+          - key: design-check-clean
+            statement: pnpm design:check reports 0 problems and pnpm design:preview reports no overflow and no serious or critical axe issue, both quoted.
+            check: { kind: evidence, evidenceKey: design-check }
+          - key: design-every-state
+            statement: Every page in the plan has its desktop board, its states and, when used on a phone, its phone board.
+            check: { kind: judge }
+      - key: review
+        name: Review
+        category: started
+        goal: Run the three read-only lenses in parallel — UX surface and consolidation; component fidelity, contrast and responsive; data contract per element (app-factory-design-review).
+        expectedOutputs:
+          - kind: document
+            label: Review findings (three lenses, by severity, with evidence)
+            relationToSubject: relates_to
+      - key: consolidate
+        name: Consolidate
+        category: started
+        goal: One writer merges the findings into a redesign brief (must-fix, boards to add, the person's questions with defaults, fidelity, real data), applies it, rebuilds and re-checks.
+        expectedOutputs:
+          - kind: document
+            label: Redesign brief
+            relationToSubject: relates_to
+        criteria:
+          - key: consolidate-nothing-dropped
+            statement: Every lens finding is applied, kept with a reason, asked as a question, or registered as a gap.
+            check: { kind: judge }
+      - key: design-approval
+        name: Design approval
+        category: started
+        goal: The person approves the canvas (and answers the brief's questions in one message), or sends it back with what to change.
+        # Gate 2 of 3: nothing is built from boards the person has not approved.
+        gate: { kind: human }
+        onFail: { toStage: consolidate }
+      - key: infra
+        name: Infra
+        category: started
+        goal: Open the platform, catalog and factory pull requests the slices need, each gap with its owner; where a gap stays open, label the bridge in the UI and the code.
+        expectedOutputs:
+          - kind: document
+            label: Infra pull requests and the gaps they close (links, owners)
+            relationToSubject: relates_to
+      - key: first-slice
+        name: Slice 1 and first look
+        category: started
+        goal: Build slice 1 from its approved boards (app-factory-build-slice), re-run every gate independently on the devbox, report VERIFIED and NEEDS-DOGFOOD, then stop for the person's first look.
+        # Gate 3 of 3: the person's first look decides the next slices.
+        gate: { kind: human }
+        onFail: { toStage: first-slice }
+        expectedOutputs:
+          - kind: document
+            label: Slice 1 report (pull request, quoted gates, differences from the boards)
+            relationToSubject: relates_to
+          - kind: devplane_deployment
+            label: Preview deployment
+            relationToSubject: relates_to
+            optional: true
+        criteria:
+          - key: slice1-gates-quoted
+            statement: pnpm verify, the screenshots, and the credential and mutation greps were re-run by the orchestrator and quoted.
+            check: { kind: evidence, evidenceKey: verify-output }
+          - key: slice1-pr-open
+            statement: Slice 1 is a pull request on the app repo; nothing was pushed to main or deployed to production.
+            check: { kind: judge }
+      - key: slices
+        name: Next slices
+        category: started
+        goal: Build the remaining slices in plan order, each with the same gates, independent verification and report.
+        expectedOutputs:
+          - kind: document
+            label: Slice reports
+            relationToSubject: relates_to
+      - key: dogfood
+        name: Dogfood
+        category: completed
+        goal: Walk the built app as the person would (every door, every state reachable), collect their verdict after real use, and report VERIFIED and NEEDS-DOGFOOD; the person sets the app's status (active) themselves.
+        expectedOutputs:
+          - kind: document
+            label: Dogfood report and the person's verdict
+            relationToSubject: relates_to
+
+  # THE DEV LOOP AS STORED CONFIG (plan v5 T2, 2026-10-27). One change = one
+  # session on its feature: shaped → building → PR opened → checks green →
+  # merged → deployed to lab → dogfooded → criteria verified. It FOLLOWS the
+  # feature's declared lifecycle (`featureStatus`, named as statusProperty, no
+  # second status): Shape writes spec, Build in_progress, PR opened in_review,
+  # Verify done (an agent's move into done proposes). The stages after PR
+  # opened carry no status — the feature stays In review until it ships.
+  #
+  # ONE human gate, at the one commitment: the lab deploy stays the person's
+  # (plan v5 decision F: a merge needs no proposal of its own; the PR outcome
+  # and this step carry it). Red checks send the work back to Build (onFail).
+  #
+  # The facts move it, not the agent's word: the staged automations
+  # `ship-a-change-*` (automations/, plan v5 T2 verbs) post the evidence the
+  # criteria below read when GitHub or the pod says the PR opened, CI finished,
+  # the PR merged or the pod deployed. The `github-read` capability lets the
+  # worker read the same facts on the person's own token.
+  #
+  # WORKER: a feature entering Spec proposes a run (the person approves who
+  # works it; a goal hands it to its agent delegate). Throttled to 5 waiting.
+  - name: Ship a change
+    description: Take a shaped change from branch to pull request, green checks, merge, lab and a dogfood walk, until its criteria are verified. The facts (PR opened, CI finished, merged, deployed) move the step; the person approves only the lab deploy.
+    goalTemplate: >-
+      Ship this change ({feature}) through one session, one branch and its pull
+      requests, then the merge, the lab and a dogfood walk, until its criteria
+      are verified. The step follows the work; move the feature's status only
+      through its lifecycle (update_entity with expectedStatus), never invent
+      one. SHAPE: write the end state and 2-5 binary criteria on this session,
+      set the feature's change type (feature, refactor or chore), and name the
+      repos it touches. BUILD: branch <type>/<slug> from origin/main in your own
+      worktree, commit in verified slices, and run the smallest gate that
+      answers for each finished slice, with its negative control; quote the
+      output. PR OPENED: open a draft pull request whose body carries the line
+      "Pod session: <this session id>", and record it on this session as the
+      outcome pr-<repo>-<number> (kind pull_request, ref url); one outcome per
+      pull request, and for each a session criterion keyed the same,
+      "<repo>#<number> is merged", checked by the capability
+      github_check_pr_merged, so the pod grades the merge itself. CHECKS: read the checks on the pull request's head with
+      github_pr_checks (the github-read capability, on the person's own token)
+      or wait for the ci.finished event; a red check sends the work back to
+      Build. MERGE: a person merges; never merge and never push to main. The
+      merge marks the outcome met. DEPLOY: ask the person for the lab deploy
+      (synap_request_deploy_approval); the deploy is their call. DOGFOOD: walk
+      the change in the running lab as a person would and report WORKS, BROKEN
+      or CANNOT-TELL with what was seen. VERIFY: grade every criterion with its
+      evidence, and separate VERIFIED (gate or check output quoted) from
+      NEEDS-DOGFOOD.
+    subjectProfile:
+      profileSlug: devplane_feature
+      statusProperty: featureStatus
+    # No stage owns these: Idea is before the change is shaped, Dropped is a
+    # person's call (humanOnly on the lifecycle).
+    humanOnlyStatuses: [backlog, cancelled]
+    activators:
+      - { on: enters_status, status: spec, mode: propose, maxPendingApprovals: 5 }
+      - { on: manual, mode: propose }
+    params:
+      - { name: feature, type: entity, label: Feature, required: true }
+    executor: is-agent
+    status: active
+    stages:
+      - key: shape
+        name: Shaped
+        category: planned
+        subjectStatus: spec
+        goal: Write the end state and 2-5 binary criteria on the session, set the feature's change type, and name the repos the change touches.
+        criteria:
+          - key: shape-criteria-written
+            statement: The session states the end state and 2-5 binary criteria a check, a judge or a person can grade.
+            check: { kind: judge }
+          - key: shape-change-typed
+            statement: The feature's change type is set (feature, refactor or chore) and the repos it touches are named.
+            check: { kind: judge }
+      - key: build
+        name: Building
+        category: started
+        subjectStatus: in_progress
+        goal: Build on a branch named after the work, from origin/main in your own worktree; commit in verified slices and run the smallest gate that answers for each finished slice, with its negative control.
+        criteria:
+          - key: build-gates-quoted
+            statement: Each finished slice was gated once (the smallest gate that answers) and its output is quoted in the room, red lines attributed against main.
+            check: { kind: judge }
+          - key: build-negative-control
+            statement: Every new test was run with its fix reverted and failed.
+            check: { kind: judge }
+      - key: pr-opened
+        name: PR opened
+        category: started
+        subjectStatus: in_review
+        goal: 'Open a draft pull request whose body carries the line "Pod session: <this session id>" and record it as the outcome pr-<repo>-<number> with its url.'
+        expectedOutputs:
+          - kind: pull_request
+            label: Pull request (outcome pr-<repo>-<number>, ref = its url)
+            relationToSubject: none
+        criteria:
+          - key: pr-opened
+            statement: A pull request for this change is open and recorded on the session as a pr-<repo>-<number> outcome with its url.
+            check: { kind: evidence, evidenceKey: pr-opened }
+          - key: pr-names-session
+            statement: The pull request body carries the line naming this Pod session.
+            check: { kind: judge }
+      - key: checks
+        name: Checks green
+        category: started
+        goal: Read the checks on the pull request's head (github_pr_checks, or the ci.finished event); fix anything red in Build.
+        gate: { kind: check }
+        onFail: { toStage: build }
+        criteria:
+          - key: checks-green
+            statement: Every required check on the pull request's head finished green.
+            check:
+              kind: evidence
+              evidenceKey: checks-green
+              hint: Posted by the ci.finished automation, or by the worker after github_pr_checks on the head sha (passed only when every run concluded success, neutral or skipped).
+      - key: merge
+        name: Merged
+        category: started
+        goal: A person merges the pull request; the merge marks the pr-<repo>-<number> outcome met and its criterion of the same key (github_check_pr_merged) grades it on GitHub's own answer. Never merge and never push to main.
+        criteria:
+          - key: merged
+            statement: The pull request is merged.
+            check:
+              kind: evidence
+              evidenceKey: merged
+              hint: Posted by the dev.pr_merged automation, or by the worker after github_pr_get (merged true).
+      - key: deploy
+        name: Deployed to lab
+        category: started
+        goal: Ask the person to deploy the merged build to lab (synap_request_deploy_approval) and record the deployed sha.
+        # The ONE commitment: a deploy is the person's call.
+        gate: { kind: human }
+        onFail: { toStage: build }
+        criteria:
+          - key: deployed
+            statement: The lab runs a build that contains the merge commit.
+            check:
+              kind: evidence
+              evidenceKey: deployed
+              hint: The deployed sha contains the merge commit (github_compare base merge commit, head deployed sha, status identical or ahead).
+      - key: dogfood
+        name: Dogfooded
+        category: started
+        goal: Walk the change in the running lab as a person would, entering through the doors a person enters through, and report WORKS, BROKEN or CANNOT-TELL with what was seen.
+        gate: { kind: check }
+        onFail: { toStage: build }
+        expectedOutputs:
+          - kind: document
+            label: Dogfood report (each path WORKS, BROKEN or CANNOT-TELL, with what was seen)
+            relationToSubject: relates_to
+        criteria:
+          - key: dogfooded
+            statement: The dogfood walk reports WORKS on every path the change touches.
+            check: { kind: evidence, evidenceKey: dogfooded }
+      - key: verify
+        name: Criteria verified
+        category: completed
+        subjectStatus: done
+        goal: Grade every criterion of the session with its evidence, separating VERIFIED (gate or check output quoted) from NEEDS-DOGFOOD; the feature reads Shipped once a person accepts it.
+        criteria:
+          - key: criteria-verified
+            statement: Every criterion of the session is graded with its evidence, and nothing unverified is reported as verified.
+            check: { kind: judge }
+
+  # The dogfood run a deploy starts (staged automation
+  # `ship-a-change-deployed`), handed to the devbox worker. A RUN of its own,
+  # not a stage, so another agent walks what the builder built. No subject
+  # (so no activator: the automation or a person starts it):
+  # one deploy carries every change merged since the last one, so the run
+  # finds the Ship a change sessions waiting at Dogfooded and grades each.
+  - name: Dogfood a change
+    description: Walk a deployed change in the running app as a person would and report WORKS, BROKEN or CANNOT-TELL, then grade the dogfood of each Ship a change session it covers.
+    goalTemplate: >-
+      Dogfood {change} in the running app ({where}) as a person would. Load the
+      dogfood skill. Enter through the doors a person enters through, reach
+      every state the change touches, and report each path WORKS, BROKEN or
+      CANNOT-TELL with a screenshot or the output seen. For each Ship a change
+      session this covers (in the same goal, waiting at Dogfooded), post the
+      evidence dogfooded on it (passed only when every path WORKS, with the
+      report as its detail). Never fix anything here: a BROKEN path becomes a
+      finding on the feature, and its session goes back to Building.
+    params:
+      - { name: change, type: text, label: "What to dogfood (a pull request, a sha, a feature)" }
+      - { name: where, type: text, label: "Where it runs (the lab host)", default: lab }
+    executor: is-agent
+    status: active
+    criteria:
+      - key: dogfood-walked
+        statement: Every path the change touches was walked in the running app and reported WORKS, BROKEN or CANNOT-TELL with what was seen.
+        check: { kind: judge }
+      - key: dogfood-graded
+        statement: Each Ship a change session covered got its dogfooded evidence, passed only when every path works.
+        check: { kind: judge }
+
 onboarding:
   goal: Capture the real engineering surface — the apps that are shipped, where their code lives, what runs behind them, where they deploy, and what's in flight — so the workspace mirrors what the team actually builds and runs, not a generic template.
   framing: >
@@ -1447,6 +2132,7 @@ onboarding:
       terminal right now, not what was true at kickoff.
   collect:
     - profileSlug: devplane_app
+      min: 1
       what: The apps that are shipped or actively being built — with where their code lives and what stack they run on.
       cardinality: several
       keyFields: [appName, appStatus, techStack, repoUrl]
@@ -1455,6 +2141,7 @@ onboarding:
       cardinality: few
       keyFields: [serviceType, serviceStatus, host]
     - profileSlug: devplane_environment
+      min: 1
       what: The servers and deploy targets the team ships to — local through production.
       cardinality: few
       keyFields: [envType, host, serverProvider]
@@ -1463,41 +2150,38 @@ onboarding:
       cardinality: several
       keyFields: [packageName, packageRegistry, dependsOn]
     - profileSlug: devplane_feature
+      min: 1
       what: The work in flight right now — features and work items with a status and priority.
       cardinality: several
       keyFields: [featureStatus, priority]
-    - profileSlug: project
-      what: The larger bounded bodies of work delegated to agents or the team, tied to a goal.
-      cardinality: few
-      keyFields: [project-status, project-goal]
   openingQuestions:
     - "What have you actually shipped, and what's still just planned? Give me the apps and their repos."
     - "For each app — what runs behind it (services, workers), and where does it deploy?"
     - "What's on your plate this week, and which of it should be delegated to agents?"
-  doneWhen: at least one app (with a repo) + its primary deploy target + one in-flight feature or project captured.
+  doneWhen: at least one app (with a repo) + its primary deploy target + one in-flight feature captured.
 
-# App reference
+# App reference — the space opens its own experience: the Work overview,
+# built from the shared lens-page components into a sandboxed frame cell that
+# this template installs (`spacePackage` below → `cell:builder-workspace:home`).
+# It replaced DevPlane, whose surface is an iframe on a localhost URL.
 app:
-  kind: native
-  appId: devplane
-  rendererType: native
-  title: DevPlane
+  kind: stored
+  cellKey: cell:builder-workspace:home
+  title: Work
 
+# The space's code (base layer). `pnpm build:space-packages` bundles each cell
+# into src/space-packages.generated.ts; the pod installs it as a frame cell.
+spacePackage:
+  cells:
+    - key: home
+      name: Work
+      source: packages/web/src/space-packages/builder/home.tsx
+
+# No DevPlane door: the space's entry is `app` above (DevPlane is a retired
+# surface; a sidebar item or a defaultApp naming it would be a second door).
 layout:
-  defaultApp: devplane
   defaultView: Task Board
   sidebarItems:
-    - kind: app
-      appId: devplane
-      label: DevPlane
-      icon: rocket
-      surface:
-        kind: app
-        appId: devplane
-        rendererType: native
-        placement: main
-        displayMode: full
-        title: DevPlane
     - kind: view
       viewName: Apps
       label: Apps
@@ -1518,6 +2202,10 @@ layout:
       viewName: Incidents
       label: Incidents
       icon: alert-triangle
+    - kind: view
+      viewName: Service Health
+      label: Services
+      icon: server
 
 bento:
   viewName: Builder Home
@@ -1526,7 +2214,7 @@ bento:
       widgetType: section-header
       pos: { x: 0, y: 0, w: 12, h: 2 }
       config:
-        title: Builder
+        title: Dev
         subtitle: Apps, packages, deployments, and delegated tasks in one lens.
         color: "#7C3AED"
     - kind: widget