@synap-core/workspace-templates 0.30.0 → 0.32.0

package/src/templates.ts

@@ -3286,12 +3286,8 @@ const DATA = {
         "description": "Turn a request for a logo, image, icon or template into a draft built from the approved brand, and approve it with a person before anything uses it.",
         "goalTemplate": "Make this brand asset ({asset}); each stage moves its status. DRAFT: read the request and the approved brand only — approved colours, fonts, references and the active token set; never a draft — and load the creative-director skill to pick the recipe. Make the draft (or up to three variants, each its own asset derived from this one) and record the generator, prompt and parameters on it. APPROVE: a person approves one draft as final; with variants, the approval asks them to `choose` one, your recommendation first, and that choice is the approval. Until then nothing may use it. Deprecating an asset is a person's call.",
         "subjectProfile": {
-          "profileSlug": "brand-asset",
-          "statusProperty": "asset-status"
+          "profileSlug": "brand-asset"
         },
-        "humanOnlyStatuses": [
-          "deprecated"
-        ],
         "params": [
           {
             "name": "asset",
@@ -3356,12 +3352,8 @@ const DATA = {
         "description": "Draft or revise the brand voice guide from what the brand already publishes, and approve it with a person.",
         "goalTemplate": "Write this brand voice guide ({guide}); each stage moves its status. DRAFT: read the brand identity, the approved assets and the last posts and emails the brand published; write the voice in a few traits, each with a do and a don't taken from real examples, and the words to use and avoid. APPROVE: a person approves the guide; then it is what every draft is checked against. Retiring a guide is a person's call.",
         "subjectProfile": {
-          "profileSlug": "brand-voice-guide",
-          "statusProperty": "voice-status"
+          "profileSlug": "brand-voice-guide"
         },
-        "humanOnlyStatuses": [
-          "deprecated"
-        ],
         "params": [
           {
             "name": "guide",
@@ -3409,12 +3401,8 @@ const DATA = {
         "description": "Distil approved references into a content guideline (base, format or the frame for one goal), and approve it with a person.",
         "goalTemplate": "Write this content guideline ({guideline}); each stage moves its status. DRAFT: read the brand identity, the approved voice guide and the approved references; load the content-taste skill. Write what to take and what to avoid as rules a maker can follow, link the guideline to every reference it was distilled from, and fill the summary. For a frame guideline, set the goal and give the structure in order. APPROVE: a person approves the guideline; then content is made and checked against it. Retiring a guideline is a person's call.",
         "subjectProfile": {
-          "profileSlug": "content-guideline",
-          "statusProperty": "guideline-status"
+          "profileSlug": "content-guideline"
         },
-        "humanOnlyStatuses": [
-          "deprecated"
-        ],
         "params": [
           {
             "name": "guideline",
@@ -3545,6 +3533,7 @@ const DATA = {
       },
       "intent": {
         "label": "Product",
+        "primary": "devplane_feature",
         "produces": [
           {
             "profile": "devplane_feature"
@@ -4661,6 +4650,23 @@ const DATA = {
         "icon": "alert-triangle",
         "color": "red",
         "description": "A production incident with severity, status, and root cause tracking",
+        "lifecycle": {
+          "property": "incidentStatus",
+          "options": [
+            {
+              "key": "open",
+              "category": "open"
+            },
+            {
+              "key": "investigating",
+              "category": "active"
+            },
+            {
+              "key": "resolved",
+              "category": "done"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "severity",
@@ -5594,6 +5600,27 @@ const DATA = {
         "icon": "workflow",
         "color": "blue",
         "description": "A user flow or business process — a sequence of steps through system components",
+        "lifecycle": {
+          "property": "workflowStatus",
+          "options": [
+            {
+              "key": "documented",
+              "category": "open"
+            },
+            {
+              "key": "in-progress",
+              "category": "active"
+            },
+            {
+              "key": "needs-review",
+              "category": "active"
+            },
+            {
+              "key": "complete",
+              "category": "done"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "workflowStatus",
@@ -5934,10 +5961,52 @@ const DATA = {
         "slug": "task-board",
         "type": "kanban",
         "scopeProfileSlug": "task",
-        "groupBy": "task-status",
+        "config": {
+          "groupByField": "task-status"
+        },
         "defaultView": true,
         "description": "All delegated tasks by status: Backlog → Queued → Running → Review → Done."
       },
+      {
+        "name": "Feature Board",
+        "slug": "feature-board",
+        "type": "kanban",
+        "scopeProfileSlug": "devplane_feature",
+        "description": "Features by stage, Idea to Shipped.",
+        "config": {
+          "groupByField": "featureStatus"
+        }
+      },
+      {
+        "name": "Story Board",
+        "slug": "story-board",
+        "type": "kanban",
+        "scopeProfileSlug": "devplane_story",
+        "description": "User stories by status, Draft to Done.",
+        "config": {
+          "groupByField": "storyStatus"
+        }
+      },
+      {
+        "name": "Issue Board",
+        "slug": "issue-board",
+        "type": "kanban",
+        "scopeProfileSlug": "issue",
+        "description": "Bugs and problems by status, Open to Fixed.",
+        "config": {
+          "groupByField": "issueStatus"
+        }
+      },
+      {
+        "name": "Design Board",
+        "slug": "design-board",
+        "type": "kanban",
+        "scopeProfileSlug": "ui-design",
+        "description": "Designs by status, from draft to implemented.",
+        "config": {
+          "groupByField": "design-status"
+        }
+      },
       {
         "name": "Deployments",
         "type": "calendar",
@@ -5981,7 +6050,9 @@ const DATA = {
         "slug": "service-health",
         "type": "kanban",
         "scopeProfileSlug": "devplane_service",
-        "groupBy": "serviceStatus",
+        "config": {
+          "groupByField": "serviceStatus"
+        },
         "description": "Every service by health — healthy, degraded, down, maintenance."
       },
       {
@@ -5989,7 +6060,9 @@ const DATA = {
         "slug": "services-by-type",
         "type": "kanban",
         "scopeProfileSlug": "devplane_service",
-        "groupBy": "serviceType",
+        "config": {
+          "groupByField": "serviceType"
+        },
         "description": "Services grouped by what they are — API, worker, cron, database, cache, queue."
       },
       {
@@ -6129,13 +6202,8 @@ const DATA = {
         "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"
+          "profileSlug": "ui-design"
         },
-        "humanOnlyStatuses": [
-          "approved",
-          "archived"
-        ],
         "activators": [
           {
             "on": "manual",
@@ -6652,13 +6720,8 @@ const DATA = {
         "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"
+          "profileSlug": "devplane_feature"
         },
-        "humanOnlyStatuses": [
-          "backlog",
-          "cancelled"
-        ],
         "activators": [
           {
             "on": "enters_status",
@@ -6907,21 +6970,12 @@ const DATA = {
       },
       {
         "name": "Build a change",
-        "description": "Dev set (decision d05), key: build. Works one feature (devplane_feature) from shaped criteria to a verified change on main; its stages follow the feature's lifecycle (spec, in_progress, in_review, done), and a cancelled or failed session puts the feature back to spec so nothing is left half-claimed. One feature per session, never two subjects (founder default, 2026-11-05). A quick change is this playbook with size small (no plan); a night shift run is this playbook with unattended true. No activators until binding is turned on; the shape would be {on: enters_status, status: spec, size: per_thing, mode: propose}, the trigger Ship a change uses today. Reuses Ship a change (2c5aa553) stage text and evidence keys; absorbs AI Dev Session and Quick change once they are re-pointed. Draft until the founder activates it.",
+        "description": "Dev set (decision d05), key: build. Works one feature (devplane_feature) from shaped criteria to a verified change on main; its stages follow the feature's lifecycle (spec, in_progress, in_review, done); a cancelled or failed session leaves the feature where it is. One feature per session, never two subjects (founder default, 2026-11-05). A quick change is this playbook with size small (no plan); a night shift run is this playbook with unattended true. No activators until binding is turned on; the shape would be {on: enters_status, status: spec, size: per_thing, mode: propose}, the trigger Ship a change uses today. Reuses Ship a change (2c5aa553) stage text and evidence keys; absorbs AI Dev Session and Quick change once they are re-pointed. Draft until the founder activates it.",
         "goalTemplate": "Build {feature} through one session and one PR per repo (or gated commits on main in a private repo), size {size}. SHAPE: write the end state and 2-5 binary criteria on this session (plan skill, skipped when size is small). BUILD: branch <type>/<slug> from origin/main in your own worktree, commit in verified slices, run the smallest gate that answers with its negative control, quote the output. LAND: follow the land stages (Change proposed, Checks green, Landed on main, Deployed to lab, Dogfooded, Criteria verified). Unattended: {unattended}. When unattended is true, ask no person, stop at a draft PR or a gated branch, never merge, push main or deploy, and post one \"Look at first:\" paragraph in the room.",
         "scope": "session",
         "subjectProfile": {
-          "onEnd": {
-            "failed": "spec",
-            "cancelled": "spec"
-          },
-          "profileSlug": "devplane_feature",
-          "statusProperty": "featureStatus"
+          "profileSlug": "devplane_feature"
         },
-        "humanOnlyStatuses": [
-          "backlog",
-          "cancelled"
-        ],
         "params": [
           {
             "name": "feature",
@@ -7160,21 +7214,12 @@ const DATA = {
       },
       {
         "name": "Fix a bug",
-        "description": "Dev set (decision d05), key: fix. Works an issue at its root: reproduce it with a failing test, fix the canonical path, a clean-context review, then the shared land stages. Its stages follow the issue's lifecycle (open, investigating, fixed); a cancelled or failed session puts the issue back to open, as Fix a finding does. Small fixes may be batched (founder default, 2026-11-05): several issues in one session, one as the subject and the rest as session targets; today a stage moves only the subject, and the session end moves the subject and every target still open. No activators until binding is turned on; a batch would be {on: count, status: open, min: 3} or {on: schedule, cron, status: open} (both one session per moment). A night shift run is this playbook with unattended true. Reuses Bugfix (8c335e2e), Night shift: build an issue (c101dd75) and Ship a change (2c5aa553). Draft until the founder activates it.",
+        "description": "Dev set (decision d05), key: fix. Works an issue at its root: reproduce it with a failing test, fix the canonical path, a clean-context review, then the shared land stages. Its stages follow the issue's lifecycle (open, investigating, fixed); a cancelled or failed session leaves the issue where it is, as Fix a finding does. Small fixes may be batched (founder default, 2026-11-05): several issues in one session, one as the subject and the rest as session targets; today a stage moves only the subject. No activators until binding is turned on; a batch would be {on: count, status: open, min: 3} or {on: schedule, cron, status: open} (both one session per moment). A night shift run is this playbook with unattended true. Reuses Bugfix (8c335e2e), Night shift: build an issue (c101dd75) and Ship a change (2c5aa553). Draft until the founder activates it.",
         "goalTemplate": "Fix the issue {issue} at its root and prove it with a test that fails before the fix and passes after. REPRODUCE (recall first, smallest reproduction, root cause file:line), FIX on the canonical path in your own worktree, a clean-context REVIEW, then LAND through the shared land stages (Change proposed, Checks green, Landed on main, Deployed to lab, Dogfooded, Criteria verified). Unattended: {unattended}. When unattended is true, ask no person, stop at a draft PR or a gated branch, never merge, push main or deploy; if no code fix is right, write the root cause as a pod document; post one \"Look at first:\" paragraph in the room.",
         "scope": "session",
         "subjectProfile": {
-          "onEnd": {
-            "failed": "open",
-            "cancelled": "open"
-          },
-          "profileSlug": "issue",
-          "statusProperty": "issueStatus"
+          "profileSlug": "issue"
         },
-        "humanOnlyStatuses": [
-          "open",
-          "wont_fix"
-        ],
         "params": [
           {
             "name": "issue",
@@ -8020,14 +8065,8 @@ const DATA = {
         "goalTemplate": "Fix the finding and see the fix live",
         "scope": "session",
         "subjectProfile": {
-          "profileSlug": "finding",
-          "statusProperty": "status"
+          "profileSlug": "finding"
         },
-        "humanOnlyStatuses": [
-          "open",
-          "wont_fix",
-          "superseded"
-        ],
         "params": [],
         "executor": "is-agent",
         "status": "active",
@@ -8300,6 +8339,27 @@ const DATA = {
         "displayName": "Question",
         "icon": "help-circle",
         "profileKind": "kind",
+        "lifecycle": {
+          "property": "questionStatus",
+          "options": [
+            {
+              "key": "open",
+              "category": "open"
+            },
+            {
+              "key": "exploring",
+              "category": "active"
+            },
+            {
+              "key": "answered",
+              "category": "done"
+            },
+            {
+              "key": "abandoned",
+              "category": "lost"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "questionStatus",
@@ -8320,6 +8380,27 @@ const DATA = {
         "displayName": "Decision",
         "icon": "gavel",
         "profileKind": "kind",
+        "lifecycle": {
+          "property": "decisionStatus",
+          "options": [
+            {
+              "key": "proposed",
+              "category": "open"
+            },
+            {
+              "key": "accepted",
+              "category": "done"
+            },
+            {
+              "key": "superseded",
+              "category": "lost"
+            },
+            {
+              "key": "rejected",
+              "category": "lost"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "decisionStatus",
@@ -8641,7 +8722,9 @@ const DATA = {
         "slug": "business-model-open-questions",
         "type": "kanban",
         "scopeProfileSlug": "question",
-        "groupBy": "questionStatus",
+        "config": {
+          "groupByField": "questionStatus"
+        },
         "description": "The nine component questions and everything they spawned, by status."
       }
     ],
@@ -9025,6 +9108,27 @@ const DATA = {
         "icon": "help-circle",
         "color": "blue",
         "description": "An open question driving a civic-data investigation.",
+        "lifecycle": {
+          "property": "questionStatus",
+          "options": [
+            {
+              "key": "open",
+              "category": "open"
+            },
+            {
+              "key": "exploring",
+              "category": "active"
+            },
+            {
+              "key": "answered",
+              "category": "done"
+            },
+            {
+              "key": "abandoned",
+              "category": "lost"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "questionStatus",
@@ -9593,7 +9697,7 @@ const DATA = {
         "scopeProfileSlug": "content-program",
         "description": "Programs grouped by status — a running scoreboard for the content operation.",
         "config": {
-          "groupBy": "status"
+          "groupByField": "status"
         }
       }
     ],
@@ -9714,7 +9818,6 @@ const DATA = {
           "musician",
           "photographer"
         ],
-        "profile": "post",
         "views": [
           "content-posts",
           "content-calendar"
@@ -9768,6 +9871,7 @@ const DATA = {
       },
       "intent": {
         "label": "Content",
+        "primary": "post",
         "produces": [
           {
             "profile": "post"
@@ -10482,6 +10586,27 @@ const DATA = {
         "color": "#0EA5E9",
         "description": "An ordered run of posts that teaches one thing end to end — the curriculum axis of the content engine.",
         "scope": "WORKSPACE",
+        "lifecycle": {
+          "property": "series-status",
+          "options": [
+            {
+              "key": "Planned",
+              "category": "open"
+            },
+            {
+              "key": "Running",
+              "category": "active"
+            },
+            {
+              "key": "Complete",
+              "category": "done"
+            },
+            {
+              "key": "Abandoned",
+              "category": "lost"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "series-status",
@@ -11645,7 +11770,9 @@ const DATA = {
         "slug": "content-posts",
         "type": "kanban",
         "scopeProfileSlug": "post",
-        "groupBy": "post-status",
+        "config": {
+          "groupByField": "post-status"
+        },
         "description": "Content posts by status."
       },
       {
@@ -11689,7 +11816,9 @@ const DATA = {
         "slug": "content-newsletters",
         "type": "kanban",
         "scopeProfileSlug": "newsletter",
-        "groupBy": "newsletter-status",
+        "config": {
+          "groupByField": "newsletter-status"
+        },
         "description": "Newsletter issues by status."
       },
       {
@@ -11985,13 +12114,8 @@ const DATA = {
         "description": "Take a briefed post from brief to script to published in any format — text, visual or video (HyperFrames) — from the pod's brand kit, one stage per post status, with a person approving the script before anything is generated.",
         "goalTemplate": "Produce content for {platform} from this idea ({post}) in the {format} format. Read the brand first from the pod's brand kit (GET /api/hub/brand/kit) — never re-derive it from a website capture — and load the creative-director skill (linked to this space) to pick the approved brand-template (layout and recipe), references and assets for this format and style; drafts never feed generation. Work the stages in order; each stage moves the post's status. SCRIPT before anything is made: write the script or outline for the format (carousel slide outline, deck outline, video script and storyboard, or the text draft) by filling the narrative frame for the post's goal — the approved content-guideline of type frame for that goal, else the default frame (sell: story, example, lesson, link; hot-take: claim, tension, reason, invitation; tutorial: promise, steps, result, next; product-demo: problem, real screen, outcome, try it). A person approves the script before the draft; nothing is generated from an unapproved script. At the draft, run the creative-director readiness check first (approved references, an approved base guideline, an approved brand-template for this format); if anything is missing, stop and route to the content-taste skill or brand onboarding instead of improvising. Then branch on the format. TEXT (article, thread, newsletter section, caption): draft it with a scroll-stopping hook and a clear CTA. VISUAL: build it pass by pass through the edit-loop skill, a person answering each pass — a carousel, LinkedIn PDF or image post as a layered composition saved on the post (carousel-format), a deck, PDF document or presentation in Open Design (open-design-edit). VIDEO (short or long video): first pick the route — FROM SCRATCH (script, storyboard, frames), FROM A VOICE (an existing voice-over or talk: transcribe it, cut on its beats, build the frames under it) or RE-EDIT (existing footage plus a voice: cut, caption, add music and motion); takes ({takes}) mean RE-EDIT, and the Draft stage says how takes, transcripts and passes are handled. Then run the HyperFrames workflow on your own agent with HYPERFRAMES_NO_TELEMETRY=1, from the kit's frame.md (format=frame-md), with GSAP vendored locally — never `hyperframes publish`, never a cloud render. For a visual or video format, record a content-composition made for this post (for a video: the brief and storyboard documents, the project zip, the MP4, key-frame stills and the brand-kit hash). Keep every format on the post's pillar and the brand voice. A human approves the script before the draft, each pass as it is built, and the draft on the preview at Review. At Schedule, a post whose account is a Postiz channel is queued through the capability that serves publish_post (postiz_schedule_post); that queueing is itself a proposal a person approves. Nothing publishes itself, and the post reads Published only once it went live: reported by Postiz, or confirmed by a person at Publish.",
         "subjectProfile": {
-          "profileSlug": "post",
-          "statusProperty": "post-status"
+          "profileSlug": "post"
         },
-        "humanOnlyStatuses": [
-          "Idea",
-          "Archived"
-        ],
         "activators": [
           {
             "on": "enters_status",
@@ -12429,8 +12553,7 @@ const DATA = {
         "description": "Turn a published post into new posts for other formats and platforms, each linked to the original.",
         "goalTemplate": "Repurpose this published post ({post}). Read what it says and how it performed, then propose one to three new pieces in other formats or on other platforms where the same idea travels (a thread from an article, a short video from a thread, a newsletter section from a series). Create each as a new post at the Idea status, on the same pillar, with its own hook, and link it derived_from the original. Never republish the original as is.",
         "subjectProfile": {
-          "profileSlug": "post",
-          "statusProperty": "post-status"
+          "profileSlug": "post"
         },
         "activators": [
           {
@@ -12466,12 +12589,8 @@ const DATA = {
         "description": "Take a newsletter issue from idea to sent — angle, draft, edit, schedule — with a person approving before it goes out.",
         "goalTemplate": "Produce this newsletter issue ({newsletter}). Read the brand voice from the pod's brand kit, then work the stages in order: settle the issue's angle and the posts it draws on, draft it, edit it down with a subject line and preview text, and schedule the send. A person approves the final issue before it is sent, nothing sends itself, and the issue reads Sent only once a person confirms it went out.",
         "subjectProfile": {
-          "profileSlug": "newsletter",
-          "statusProperty": "newsletter-status"
+          "profileSlug": "newsletter"
         },
-        "humanOnlyStatuses": [
-          "Archived"
-        ],
         "params": [
           {
             "name": "newsletter",
@@ -13206,7 +13325,6 @@ const DATA = {
           "small-business",
           "founder"
         ],
-        "profile": "deal",
         "views": [
           "deal-pipeline",
           "deals-table",
@@ -13265,6 +13383,7 @@ const DATA = {
       },
       "intent": {
         "label": "Sales",
+        "primary": "deal",
         "produces": [
           {
             "profile": "lead"
@@ -14238,10 +14357,9 @@ const DATA = {
         "slug": "outreach-touches",
         "type": "kanban",
         "scopeProfileSlug": "outreach-touch",
-        "groupBy": "status",
         "description": "Every outreach message, grouped by where it stands — drafted for a person to send, through replied.",
         "config": {
-          "groupBy": "status",
+          "groupByField": "status",
           "cardFields": [
             "channel",
             "touchType",
@@ -14341,17 +14459,8 @@ const DATA = {
         "description": "Research one lead, decide with a person whether it is worth pursuing, and set a pursued lead qualified with \"book a meeting\" as its next action.",
         "goalTemplate": "Qualify this lead ({lead}). RESEARCH: verify and enrich only facts you can support — company, role, size, recent signal — and record the source of each. SCORE: assess fit against the offers and the ideal client, set the ICP score, qualification notes and outreach channels, and write the step you recommend as the lead's next action: `nextAction` one imperative line (e.g. \"Send the first message on LinkedIn\") and `nextActionAt` its date. DECIDE: ask the person to `choose` pursue, nurture or drop, your recommendation first; that answer is the decision. NURTURE: set the lead to nurturing, with `nextAction` to check in again and `nextActionAt` the date they gave (three months out when they gave none). DROP: write their reason in `disqualificationReason` and move the lead to disqualified; that move is the person's (disqualified is human-only), so it comes back proposed for them to approve, which is success; never write it another way. PURSUE: only when they chose pursue, set the lead to qualified with `nextAction` \"Book a meeting\" (one line naming the channel, e.g. \"Ask for a meeting on LinkedIn\") and `nextActionAt` its date. Never create a deal: a deal is opened when a person records a booked meeting, and that same step converts the lead. Never mark the lead a client.",
         "subjectProfile": {
-          "profileSlug": "lead",
-          "statusProperty": "leadStage"
-        },
-        "humanOnlyStatuses": [
-          "new",
-          "outreach",
-          "engaged",
-          "nurturing",
-          "converted",
-          "disqualified"
-        ],
+          "profileSlug": "lead"
+        },
         "activators": [
           {
             "on": "manual",
@@ -14475,12 +14584,8 @@ const DATA = {
         "description": "Take a deal from first conversation to won or lost — qualify it, write and send the proposal, negotiate, and hand a won deal to delivery, with a person deciding every commitment.",
         "goalTemplate": "Work this deal ({deal}) through its stages; each stage moves the deal's commercial stage. QUALIFY: from the pod (the company, its people, every past message and meeting) and public sources, establish the four facts a proposal needs — the problem the buyer wants solved and what it costs them, a budget range, who signs, and when they need it — and link the people involved to the deal. Do not guess a fact: when one is missing, ask the person who owns the relationship. WRITE: draft the proposal document (scope, deliverables, timeline, price, terms) from the agency's offers and past won proposals, and set the deal's value and close date. SEND: a person approves the proposal before it goes to the client; nothing is sent without that approval. AWAIT: wait for the client's answer and record it on the deal. NEGOTIATE: its check reads that answer; log every objection and counter-offer and propose the next step. WON: once a person confirms the client said yes, reuse the engagement Operations already has for this company; only when there is none, open one at proposed with its client set to the company. Then attach the client role to the company with handoff status handed_off. The daily \"Pick up handed-off clients\" automation skips any client that already has an engagement, so no second one is opened. A lost deal is a person's call — record why it was lost.",
         "subjectProfile": {
-          "profileSlug": "deal",
-          "statusProperty": "commercialStage"
+          "profileSlug": "deal"
         },
-        "humanOnlyStatuses": [
-          "lost"
-        ],
         "activators": [
           {
             "on": "created",
@@ -15188,8 +15293,7 @@ const DATA = {
         "description": "Each weekday, read the channels of the leads in outreach; summarise a reply and propose the next step, or, when the follow-up is due with no reply, draft the next message in the angle of its outreach campaign as a proposed message for a person to approve; the agent never sends.",
         "goalTemplate": "Follow up on the leads in outreach. For each, read its channels (synap_get_channel, mode person: for a company lead, the channels of the person who decides there) and its notes. A REPLY is an inbound message after our last outbound one in a channel. With a reply, draft nothing: summarise it for a person; when they show interest, propose the next step (prepare the free estimate, \"Prepare a pre-sale estimate\", or book a meeting) and propose moving the lead to engaged; when they decline, propose nurturing or disqualified with their reason (in disqualificationReason). Unless you propose dropping them, write the next step on the lead as nextAction, one imperative line, and nextActionAt, the date they named or today. Never open a deal and never answer the reply yourself; a person does. With no reply, and only when the lead's next action date is today or past and no proposed message to it is still waiting, draft the next message, to the lead (for a company, the person who decides there) and in the angle of the lead's outreach campaign: follow its value proposition and call to action, short and in the lead's language, offering the next useful step, never pressure. For a lead with no campaign, ask the person which one. Draft at most two follow-ups per lead: a lead already sent two follow-ups gets no draft, never a third follow-up; when its last date passes in silence, propose moving it to nurturing through the status door, with its expected status. DRAFT RULES: each draft is one proposed message in the channel of the person it is written to, filed through the pod's send door: run messaging.send with to = that person's entity id (for a company lead, its decider: when that person is not in the pod, create them through the entity door with only their own fields, such as name, role and LinkedIn URL, never the company's website, domain or email), text = the message, and provider linkedin or email. Read their channel first (synap_get_channel, mode person) for what was already said. The pod files it for a person to review in that channel; it goes out only once they approve it. Never call a tool's own send verb (Unipile, Gmail), never create an outreach touch, a note or a task holding the message, and never use synap_capture for it. Never send. A LinkedIn message is drafted whatever their reach: the pod holds a draft to someone who is not a connection yet, shows it with the next step and lets it go out once they connect, so never hold a draft back for want of a connection. Draft it, then, in this order: (1) a person with no linkedinUrl: find their profile with linkedin_find_profile (their full name and company); on a match, propose its linkedinUrl and linkedinProviderId on the person for a person to approve; on none or several, ask the person to choose among its candidates (the process \"Find their LinkedIn\" does this for one lead). (2) Read their linkedinConnection, which only the pod writes (never set it or linkedinInvitedAt): connected, nothing more; none or not set, ask to connect with linkedin_send_invite (it refuses someone already connected or already invited: then nothing more); pending, the draft waits for them; ignored, draft by email instead when they have an email address. While the draft waits for them to connect, set the lead's nextAction to \"Wait for <name> to accept the LinkedIn request\" and its nextActionAt 7 days later. An email message needs none of this. For each draft, set the lead's `nextAction` to send it (e.g. \"Send the drafted message to Ana on LinkedIn\") and `nextActionAt` to today. The person reviews each proposed message in its channel, edits it if needed and approves it; the agent never sends. CADENCE: when a message is sent (a person approved its proposed message, so it is an outbound message in the channel), set its lead's lastContactedAt to the sent day, count the messages sent to the lead (the outbound messages in its channels, read with synap_get_channel mode person: for a company lead, the channels of the person written to there), and set the lead's next action: after the first message, nextAction \"Follow up with <name> if no reply\" and nextActionAt the sent day + 3 days; after the first follow-up, nextAction \"Follow up with <name> a last time if no reply\" and nextActionAt the sent day + 7 days; after the second follow-up, nextAction \"No reply after two follow-ups: nurture or drop <name>\" and nextActionAt the sent day + 7 days, and when that date passes with no reply, \"Follow up on leads in outreach\" proposes nurturing. Never a third follow-up. Propose moving a lead at new or researching to outreach through the status door, with its expected status. A reply stops the cadence: a reply is an inbound message after our last outbound one in the channel, and \"Follow up on leads in outreach\" reads it and proposes the next step.",
         "subjectProfile": {
-          "profileSlug": "lead",
-          "statusProperty": "leadStage"
+          "profileSlug": "lead"
         },
         "activators": [
           {
@@ -15275,13 +15379,8 @@ const DATA = {
         "description": "Run one outreach campaign — write the angle and its offer, pick the people, draft one personal first message each as a proposed message in their channel; a person approves the list, then approves each message, which the pod sends.",
         "goalTemplate": "Run this outreach campaign ({campaign}) on {channel}; each stage moves its status. If its type is not outreach, stop and say so. PREPARE: write the target audience, the value proposition and the call to action. Pick the people to reach from the pod (and public sources when the pod has too few), resolving each one before creating anything, link each as a member of the campaign with the lead role (lead source cold-outreach when it has none), and for each draft one first message to that person in this campaign's angle, specific to them — their company, role and any past message — never a generic template. DRAFT RULES: each draft is one proposed message in the channel of the person it is written to, filed through the pod's send door: run messaging.send with to = that person's entity id (for a company lead, its decider: when that person is not in the pod, create them through the entity door with only their own fields, such as name, role and LinkedIn URL, never the company's website, domain or email), text = the message, and provider linkedin or email. Read their channel first (synap_get_channel, mode person) for what was already said. The pod files it for a person to review in that channel; it goes out only once they approve it. Never call a tool's own send verb (Unipile, Gmail), never create an outreach touch, a note or a task holding the message, and never use synap_capture for it. Never send. A LinkedIn message is drafted whatever their reach: the pod holds a draft to someone who is not a connection yet, shows it with the next step and lets it go out once they connect, so never hold a draft back for want of a connection. Draft it, then, in this order: (1) a person with no linkedinUrl: find their profile with linkedin_find_profile (their full name and company); on a match, propose its linkedinUrl and linkedinProviderId on the person for a person to approve; on none or several, ask the person to choose among its candidates (the process \"Find their LinkedIn\" does this for one lead). (2) Read their linkedinConnection, which only the pod writes (never set it or linkedinInvitedAt): connected, nothing more; none or not set, ask to connect with linkedin_send_invite (it refuses someone already connected or already invited: then nothing more); pending, the draft waits for them; ignored, draft by email instead when they have an email address. While the draft waits for them to connect, set the lead's nextAction to \"Wait for <name> to accept the LinkedIn request\" and its nextActionAt 7 days later. An email message needs none of this. START: a person approves the audience, the offer and the list, then reviews each proposed message in its channel and approves it; nothing goes out before they approve it, and the agent never sends. Once a message is sent, follow the cadence, so \"Follow up on leads in outreach\" drafts the next one. CADENCE: when a message is sent (a person approved its proposed message, so it is an outbound message in the channel), set its lead's lastContactedAt to the sent day, count the messages sent to the lead (the outbound messages in its channels, read with synap_get_channel mode person: for a company lead, the channels of the person written to there), and set the lead's next action: after the first message, nextAction \"Follow up with <name> if no reply\" and nextActionAt the sent day + 3 days; after the first follow-up, nextAction \"Follow up with <name> a last time if no reply\" and nextActionAt the sent day + 7 days; after the second follow-up, nextAction \"No reply after two follow-ups: nurture or drop <name>\" and nextActionAt the sent day + 7 days, and when that date passes with no reply, \"Follow up on leads in outreach\" proposes nurturing. Never a third follow-up. Propose moving a lead at new or researching to outreach through the status door, with its expected status. A reply stops the cadence: a reply is an inbound message after our last outbound one in the channel, and \"Follow up on leads in outreach\" reads it and proposes the next step. FINISH: when every person written to has replied or their follow-ups ended in silence, record in the campaign notes how many messages were sent (the outbound messages in their channels), how many got a reply and how many led to a booked meeting. Pausing or cancelling is a person's call.",
         "subjectProfile": {
-          "profileSlug": "campaign",
-          "statusProperty": "campaign-status"
+          "profileSlug": "campaign"
         },
-        "humanOnlyStatuses": [
-          "paused",
-          "cancelled"
-        ],
         "activators": [
           {
             "on": "created",
@@ -15383,15 +15482,8 @@ const DATA = {
         "description": "Once a person has marked an outreach touch sent (messages recorded before the channels), watch for the reply; summarise it and propose the next step — the free estimate or a meeting — and never open a deal.",
         "goalTemplate": "Watch this sent outreach message ({touch}) for a reply; each stage moves its status. WAIT: watch its conversation. Set it bounced when it did not reach the person, or no response when its lead's next action date passes with no reply; that date is the cadence's (the sent day + 3 days after the first message, the sent day + 7 days after each follow-up), so when the lead has none, count from this message's sent date. The next message is drafted by \"Follow up on leads in outreach\", not here. When this message is the second follow-up (the third message sent to the lead) and its date passes with no reply, mark it no response and propose moving the lead to nurturing through the status door, with its expected status; there is never a third follow-up. REPLIED: its check reads the reply. Summarise it for a person. When they show interest, propose the next step — prepare the free estimate (\"Prepare a pre-sale estimate\") or book a meeting — and propose moving the lead to engaged; when they decline, propose nurturing or disqualified with their reason (in `disqualificationReason`). Unless you propose dropping them, write the next step you propose on the lead as `nextAction`, one imperative line (e.g. \"Book a meeting with Ana\"; \"Check in again\" for nurturing), and `nextActionAt`, the date they named or today; never leave it only in the summary. BOUNCED: set the lead's `nextAction` to find another way to reach them and `nextActionAt` to today. Never open a deal: a deal is opened only when a person records a booked meeting. Never answer the reply yourself; a person does. Opened is recorded by a person.",
         "subjectProfile": {
-          "profileSlug": "outreach-touch",
-          "statusProperty": "status"
-        },
-        "humanOnlyStatuses": [
-          "drafted",
-          "sent",
-          "opened",
-          "replaced"
-        ],
+          "profileSlug": "outreach-touch"
+        },
         "activators": [
           {
             "on": "enters_status",
@@ -16387,6 +16479,7 @@ const DATA = {
       "isPublic": true,
       "intent": {
         "label": "Finance",
+        "primary": "invoice",
         "produces": [
           {
             "profile": "invoice"
@@ -16982,15 +17075,24 @@ const DATA = {
           }
         }
       },
+      {
+        "name": "Invoice Board",
+        "slug": "invoice-board",
+        "type": "kanban",
+        "scopeProfileSlug": "invoice",
+        "description": "Invoices by status, draft to paid — the flow board of Bill a client.",
+        "config": {
+          "groupByField": "status"
+        }
+      },
       {
         "name": "Expenses",
         "slug": "expenses",
         "type": "kanban",
         "scopeProfileSlug": "expense",
-        "groupBy": "status",
         "description": "Accounts payable and spend, grouped by approval/payment status.",
         "config": {
-          "groupBy": "status",
+          "groupByField": "status",
           "cardFields": [
             "category",
             "amount",
@@ -17296,12 +17398,8 @@ const DATA = {
         "description": "Take an invoice from draft to paid — prepare it, send it with a person's approval, chase it when late, and confirm the payment.",
         "goalTemplate": "Bill this invoice ({invoice}); each stage moves its status. PREPARE: set the invoice number, customer, amount, currency, issue date and due date from the engagement or deal it bills, and check the amount against what was agreed. SEND: a person approves the invoice before it goes to the client; record the issue date. DUE: wait for the payment; look for it in the bank or payment provider (match the amount and the reference), and move on once it is found or the due date has passed. PAID: its check reads the payment; set the paid date and link the account it was deposited to. When the due date passed unpaid, the check sends the run to CHASE instead: the invoice becomes overdue and you draft a polite reminder for a person to send; once the payment is found, move the run back to Paid. Voiding an invoice is a person's call.",
         "subjectProfile": {
-          "profileSlug": "invoice",
-          "statusProperty": "status"
+          "profileSlug": "invoice"
         },
-        "humanOnlyStatuses": [
-          "void"
-        ],
         "activators": [
           {
             "on": "created",
@@ -17459,13 +17557,8 @@ const DATA = {
         "description": "Review an expense against its budget, get a person's approval, and record the payment.",
         "goalTemplate": "Handle this expense ({expense}); each stage moves its status. REVIEW: check the vendor, amount, date, category and receipt, link the budget it counts against and say how much of that budget is left after it. APPROVE: a person approves or rejects the spend. PAY: a person confirms it was paid; link the account it was paid from. Reimbursement and rejection are a person's call.",
         "subjectProfile": {
-          "profileSlug": "expense",
-          "statusProperty": "status"
+          "profileSlug": "expense"
         },
-        "humanOnlyStatuses": [
-          "reimbursed",
-          "rejected"
-        ],
         "activators": [
           {
             "on": "created",
@@ -18476,9 +18569,8 @@ const DATA = {
         "slug": "pain-points",
         "type": "kanban",
         "scopeProfileSlug": "pain-point",
-        "groupBy": "severity",
         "config": {
-          "groupBy": "severity",
+          "groupByField": "severity",
           "cardFields": [
             "description",
             "audience",
@@ -20522,6 +20614,7 @@ const DATA = {
       "isPublic": true,
       "intent": {
         "label": "Team",
+        "primary": "candidate",
         "produces": [
           {
             "profile": "candidate"
@@ -21089,10 +21182,9 @@ const DATA = {
         "slug": "reviews",
         "type": "kanban",
         "scopeProfileSlug": "review",
-        "groupBy": "status",
         "description": "Performance reviews across the cycle, by status.",
         "config": {
-          "groupBy": "status",
+          "groupByField": "status",
           "cardFields": [
             "cycle",
             "rating",
@@ -21898,7 +21990,6 @@ const DATA = {
         "slug": "workflows",
         "type": "kanban",
         "scopeProfileSlug": "workflow",
-        "groupBy": "workflow-status",
         "description": "Recurring processes on a board by status.",
         "config": {
           "groupByField": "workflow-status",
@@ -22278,6 +22369,7 @@ const DATA = {
       "isPublic": true,
       "intent": {
         "label": "Legal",
+        "primary": "legal-contract",
         "produces": [
           {
             "profile": "legal-contract"
@@ -22885,10 +22977,9 @@ const DATA = {
         "slug": "renewals",
         "type": "kanban",
         "scopeProfileSlug": "legal-contract",
-        "groupBy": "status",
         "description": "Contracts by lifecycle stage — catch renewals and expirations before they bite.",
         "config": {
-          "groupBy": "status",
+          "groupByField": "status",
           "cardFields": [
             "counterparty",
             "renewalType",
@@ -22903,10 +22994,9 @@ const DATA = {
         "slug": "compliance",
         "type": "kanban",
         "scopeProfileSlug": "compliance-item",
-        "groupBy": "status",
         "description": "Obligations by status — nothing goes overdue.",
         "config": {
-          "groupBy": "status",
+          "groupByField": "status",
           "cardFields": [
             "obligationType",
             "jurisdiction",
@@ -25675,6 +25765,7 @@ const DATA = {
       "isPublic": true,
       "intent": {
         "label": "Marketing",
+        "primary": "campaign",
         "produces": [
           {
             "profile": "campaign"
@@ -26023,7 +26114,9 @@ const DATA = {
         "slug": "campaigns",
         "type": "kanban",
         "scopeProfileSlug": "campaign",
-        "groupBy": "campaign-status",
+        "config": {
+          "groupByField": "campaign-status"
+        },
         "description": "Campaign kanban board by status."
       },
       {
@@ -26164,13 +26257,8 @@ const DATA = {
         "description": "Take a campaign from brief to results — goal, audience, plan, content, launch with a person's approval, and a report on the leads it brought.",
         "goalTemplate": "Run this campaign ({campaign}); each stage moves its status. BRIEF: write the campaign's goal as a number, its target audience, channel, budget, start and end dates, from the brand kit and the agency's offers. PLAN: list the pieces to make and the outreach to send, each with a date. MAKE: create each piece as a post at the Idea status in Content OS and each outreach sequence as an outreach campaign, so their own processes produce them. LAUNCH: a person approves the launch; nothing is published, sent or paid for before that. REPORT: after the end date, record the lead count and conversion rate, link every new lead the campaign brought, and write what worked and what to change. Pausing or cancelling is a person's call.",
         "subjectProfile": {
-          "profileSlug": "campaign",
-          "statusProperty": "campaign-status"
+          "profileSlug": "campaign"
         },
-        "humanOnlyStatuses": [
-          "paused",
-          "cancelled"
-        ],
         "activators": [
           {
             "on": "created",
@@ -26533,10 +26621,9 @@ const DATA = {
         "slug": "meeting-action-items",
         "type": "kanban",
         "scopeProfileSlug": "task",
-        "groupBy": "status",
         "description": "Tasks generated from meetings, by status.",
         "config": {
-          "groupBy": "status"
+          "groupByField": "status"
         }
       }
     ],
@@ -27475,7 +27562,6 @@ const DATA = {
         "suggestFor": [
           "consultant"
         ],
-        "profile": "engagement",
         "views": [
           "engagements"
         ],
@@ -27521,6 +27607,7 @@ const DATA = {
       },
       "intent": {
         "label": "Delivery",
+        "primary": "engagement",
         "produces": [
           {
             "profile": "engagement"
@@ -27936,7 +28023,9 @@ const DATA = {
         "slug": "engagements",
         "type": "kanban",
         "scopeProfileSlug": "engagement",
-        "groupBy": "engagement-status",
+        "config": {
+          "groupByField": "engagement-status"
+        },
         "description": "Client engagements on a board by status."
       },
       {
@@ -27944,7 +28033,9 @@ const DATA = {
         "slug": "deliverables",
         "type": "kanban",
         "scopeProfileSlug": "deliverable",
-        "groupBy": "deliverable-status",
+        "config": {
+          "groupByField": "deliverable-status"
+        },
         "description": "Deliverables on a board by status."
       },
       {
@@ -27954,6 +28045,16 @@ const DATA = {
         "scopeProfileSlug": "contract",
         "description": "Contracts with their status, value, and term."
       },
+      {
+        "name": "Contract Board",
+        "slug": "contract-board",
+        "type": "kanban",
+        "scopeProfileSlug": "contract",
+        "description": "Contracts by status — the flow board of Get a contract signed.",
+        "config": {
+          "groupByField": "contract-status"
+        }
+      },
       {
         "name": "Client Briefings",
         "slug": "client-briefings",
@@ -28576,13 +28677,8 @@ const DATA = {
         "description": "Run one client engagement from kick-off to close — scope, contract, deliverables, final review and the closing invoice — with a person approving the start and the close.",
         "goalTemplate": "Run this client engagement ({engagement}); each stage moves its status. KICK-OFF: read the won deal, the proposal and every message with the client; write the scope, owner, start and end dates and value on the engagement; create one deliverable per promised output (each with a due date and an owner); reuse the draft contract already linked to the engagement (the daily client pick-up opens one), and create a draft contract only when none is linked. START: a person confirms the contract is signed and the work may start. DELIVER: track every deliverable to accepted (or cancelled by a person), post a short weekly status in this session's room, and flag any deliverable past its due date. CLOSE: once every deliverable is accepted or cancelled, write the closing review (what was delivered, what slipped, what the client said), create the closing invoice in Finance at the draft status for the engagement value still owed (when the engagement bills per deliverable, subtract every milestone invoice already created for it), and propose the renewal or next engagement. A person approves the close. Pausing or cancelling an engagement is a person's call.",
         "subjectProfile": {
-          "profileSlug": "engagement",
-          "statusProperty": "engagement-status"
+          "profileSlug": "engagement"
         },
-        "humanOnlyStatuses": [
-          "on-hold",
-          "cancelled"
-        ],
         "activators": [
           {
             "on": "created",
@@ -28716,13 +28812,8 @@ const DATA = {
         "description": "Take one deliverable from in progress to accepted by the client — plan, produce, review internally, send, get the client's sign-off, and bill it when the engagement bills per deliverable.",
         "goalTemplate": "Deliver this deliverable ({deliverable}); each stage moves its status. PLAN: read the engagement's scope and the client's brief, and write what done looks like for this deliverable. PRODUCE: make it, or break it into tasks for the people who will. REVIEW: check it against what done looks like before anyone outside sees it. SEND: a person approves before it goes to the client; record the date it was delivered. ACCEPTED: a person confirms the client accepted it; if the client asked for changes, go back to producing. Then read the engagement's billing: only when it bills per deliverable, create this deliverable's invoice in Finance at the draft status for its share of the engagement value, linked to the deliverable. When it bills at close, create no invoice; the engagement's close bills it.",
         "subjectProfile": {
-          "profileSlug": "deliverable",
-          "statusProperty": "deliverable-status"
+          "profileSlug": "deliverable"
         },
-        "humanOnlyStatuses": [
-          "not-started",
-          "cancelled"
-        ],
         "activators": [
           {
             "on": "enters_status",
@@ -28851,13 +28942,8 @@ const DATA = {
         "description": "Take a client contract from draft to signed and active, with a person approving what is sent and confirming the signature.",
         "goalTemplate": "Get this contract ({contract}) signed; each stage moves its status. DRAFT: fill the contract from the engagement's scope, value, dates and the agency's standard terms, and list every term that differs from the standard. SEND: a person approves the contract before it goes to the client. SIGNED: ask the person to `provide` the signed file; their approval confirms both sides signed. ACTIVE: set the start and end dates and link the signed document. Expiry and termination are a person's call.",
         "subjectProfile": {
-          "profileSlug": "contract",
-          "statusProperty": "contract-status"
+          "profileSlug": "contract"
         },
-        "humanOnlyStatuses": [
-          "expired",
-          "terminated"
-        ],
         "activators": [
           {
             "on": "created",
@@ -28970,6 +29056,7 @@ const DATA = {
       "isPublic": true,
       "intent": {
         "label": "Planning",
+        "primary": "sprint",
         "produces": [
           {
             "profile": "sprint"
@@ -29258,7 +29345,6 @@ const DATA = {
         "slug": "sprint-board",
         "type": "kanban",
         "scopeProfileSlug": "task",
-        "groupBy": "task-status",
         "description": "Active sprint tasks in Backlog / Todo / In Progress / Review / Done lanes",
         "config": {
           "groupByField": "task-status",
@@ -29374,7 +29460,6 @@ const DATA = {
         "slug": "retrospective-board",
         "type": "kanban",
         "scopeProfileSlug": "sprint",
-        "groupBy": "sprint-status",
         "description": "Sprint retrospectives — completed sprints with retrospective notes attached as documents",
         "config": {
           "groupByField": "sprint-status"
@@ -30232,6 +30317,7 @@ const DATA = {
       "isPublic": true,
       "intent": {
         "label": "Research",
+        "primary": "research-finding",
         "produces": [
           {
             "profile": "hypothesis"
@@ -30262,6 +30348,27 @@ const DATA = {
         "icon": "help-circle",
         "color": "blue",
         "description": "An open question driving an investigation — the thing research answers.",
+        "lifecycle": {
+          "property": "questionStatus",
+          "options": [
+            {
+              "key": "open",
+              "category": "open"
+            },
+            {
+              "key": "exploring",
+              "category": "active"
+            },
+            {
+              "key": "answered",
+              "category": "done"
+            },
+            {
+              "key": "abandoned",
+              "category": "lost"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "questionStatus",
@@ -30647,10 +30754,9 @@ const DATA = {
         "slug": "research-hypotheses",
         "type": "kanban",
         "scopeProfileSlug": "hypothesis",
-        "groupBy": "stance",
         "description": "Candidate theories, grouped by where the evidence has left them.",
         "config": {
-          "groupBy": "stance"
+          "groupByField": "stance"
         }
       },
       {
@@ -30774,12 +30880,8 @@ const DATA = {
         "description": "Investigate a question end-to-end — gather and rank sources (keeping the rejected ones), weigh hypotheses, emit findings with calibrated confidence, and map them onto the knowledge graph.",
         "goalTemplate": "Investigate the question {question} and record the WHOLE investigation, not just the answer; each stage moves the question's status. FRAME: restate the question so it can be answered, and say what evidence would answer it. GATHER: use the source-triage skill to gather sources widely via web search, classify each by type and credibility, and create a `source` entity for every one — including the ones you rejected, marked rejected with a reason (never silently drop a source). WEIGH: form the candidate answers as `hypothesis` entities that answer the question; link every source that bears on a hypothesis with `supports` or `contradicts`; use the evidence-synthesis skill to emit `research-finding` entities with honestly calibrated confidence, each `supported_by` its sources and `derived_from` this research; use the concept-cartography skill to place the findings onto the knowledge map. ANSWER: create the `research` entity that `investigates` the question and `explored` the sources, write its conclusion and confidence, and set the question to answered. Abandoning a question is a person's call. Every write is proposal-gated and reviewable.",
         "subjectProfile": {
-          "profileSlug": "question",
-          "statusProperty": "questionStatus"
+          "profileSlug": "question"
         },
-        "humanOnlyStatuses": [
-          "abandoned"
-        ],
         "activators": [
           {
             "on": "created",
@@ -30893,8 +30995,7 @@ const DATA = {
         "description": "When a finding is validated, propose the posts that would share it, each linked to the finding.",
         "goalTemplate": "Turn this validated finding ({finding}) into content. Read the finding, its sources and the research it came from. Propose one to three posts that share it with the audience — each created at the Idea status, on the pillar it fits, with its hook and the reason it is worth making — and link each one derived_from the finding. Quote only what the sources support.",
         "subjectProfile": {
-          "profileSlug": "research-finding",
-          "statusProperty": "status"
+          "profileSlug": "research-finding"
         },
         "activators": [
           {
@@ -31097,6 +31198,27 @@ const DATA = {
         "icon": "help-circle",
         "color": "blue",
         "description": "The open question being decided.",
+        "lifecycle": {
+          "property": "questionStatus",
+          "options": [
+            {
+              "key": "open",
+              "category": "open"
+            },
+            {
+              "key": "exploring",
+              "category": "active"
+            },
+            {
+              "key": "answered",
+              "category": "done"
+            },
+            {
+              "key": "abandoned",
+              "category": "lost"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "questionStatus",
@@ -31171,6 +31293,27 @@ const DATA = {
         "icon": "scale",
         "color": "amber",
         "description": "A resolved decision — the recommendation, why it won, and the alternatives that lost (and why).",
+        "lifecycle": {
+          "property": "decisionStatus",
+          "options": [
+            {
+              "key": "proposed",
+              "category": "open"
+            },
+            {
+              "key": "accepted",
+              "category": "done"
+            },
+            {
+              "key": "superseded",
+              "category": "lost"
+            },
+            {
+              "key": "rejected",
+              "category": "lost"
+            }
+          ]
+        },
         "properties": [
           {
             "slug": "summary",
@@ -31275,13 +31418,8 @@ const DATA = {
         "description": "Put a proposed decision in front of a person with its options and evidence, and record what they chose.",
         "goalTemplate": "Bring this decision ({decision}) to a person. Summarise the question it resolves, the options that were considered, the evidence for and against each, and the recommendation, in one screen. A person accepts or rejects it. When a later decision replaces it, the person marks it superseded.",
         "subjectProfile": {
-          "profileSlug": "decision",
-          "statusProperty": "decisionStatus"
+          "profileSlug": "decision"
         },
-        "humanOnlyStatuses": [
-          "superseded",
-          "rejected"
-        ],
         "activators": [
           {
             "on": "created",
@@ -31369,6 +31507,7 @@ const DATA = {
       "isPublic": true,
       "intent": {
         "label": "Distribution",
+        "primary": "post",
         "produces": [
           {
             "profile": "post"
@@ -31753,7 +31892,9 @@ const DATA = {
         "slug": "content-calendar",
         "type": "kanban",
         "scopeProfileSlug": "post",
-        "groupBy": "post-status",
+        "config": {
+          "groupByField": "post-status"
+        },
         "description": "Posts on a board by status — idea to published."
       },
       {