@higrowth/cli 0.3.4 → 0.3.5

package/dist/index.js

@@ -726,7 +726,7 @@ Plans are not giant backlogs. A good plan is a scoped intervention:
 one topic area, page cluster, gap type, or conversion slice with enough
 evidence to act and narrow enough boundaries to avoid conflicting work.
 
-The planning stack has five layers:
+The planning stack has six layers:
 
 1. **Answer map** \u2014 what questions the site answers for which persona
    and decision stage.
@@ -741,12 +741,17 @@ The planning stack has five layers:
 5. **Scoped plans** \u2014 a small selected scope that generates execution
    items from roadmap rows, scoped gaps, pages, answer cells, or decision
    candidates.
+6. **Authored plans** \u2014 when the harness can synthesize the right
+   strategic shape better than the built-in generator, it may write the
+   staging plan artifact directly into HG via the authored-plan API,
+   using HG signals as evidence.
 
 Rank by **leverage, evidence, and executability**, not raw opportunity count.
 Never create work orders directly from imagination candidates. Promote
 good imagination candidates into decision candidates first, then plan.
 Roadmap rows do not need promotion: use them directly when the user's
-intent is to execute a topic roadmap.
+intent is to execute a topic roadmap. Authored plans do not bypass
+review or execution approval: they create/edit staging plan artifacts.
 
 ## The conversation
 
@@ -1122,7 +1127,126 @@ console.log(detail.items.map(i => ({
 Explain what to review and which first 1-3 items are safest to move into
 execution.
 
-### Step 10 \u2014 Generate content briefs when the plan item is ready
+### Step 10 \u2014 Or hand-author the plan when the harness can do better
+
+If the user wants a specific strategic outcome and the built-in plan
+generator is producing the wrong shape, the harness may directly author
+the plan into HG. This is allowed. Do it only after reading enough HG
+context to make the plan useful: diagnostic narrative, topic/pillar ids,
+topic roadmap rows, decision candidates, gaps, page signals,
+strategy/KB facts, and user constraints from the conversation.
+
+Use this path when the outcome is "get the right plan artifact into HG"
+rather than "let HG generate whatever it thinks is next." The import
+creates a staging plan with provenance; it does not dispatch work.
+
+\`\`\`ts
+const imported = await api.post(\`/api/entities/\${entityId}/plans/import\`, {
+  source: 'codex-harness',
+  name: 'Decision-stage proof sprint',
+  description: 'Tighten evaluation pages around buyer objections and proof gaps.',
+  narrative: [
+    'The strategic bet is...',
+    'The evidence says...',
+    'The execution risk is...',
+    'The expected outcome is...',
+  ].join('
+
+'),
+  kind: 'scoped_plan',
+  topicId,
+  mode: 'grow',
+  contextManifest: {
+    diagnosticId,
+    topicId,
+    roadmapItemIds: openRoadmapItems.map(item => item.id),
+    decisionCandidateIds: selected?.decisionCandidateIds ?? [],
+    gapIds: selected?.gapIds ?? [],
+    pageIds: selected?.pageIds ?? [],
+  },
+  inputSnapshot: {
+    userIntent: q,
+    selectedScope: selected ?? null,
+    preview: preview ?? null,
+    openRoadmapItems,
+    topDecisionCandidates: decisions.candidates.slice(0, 10),
+  },
+  items: [
+    {
+      type: 'manual',
+      kind: 'page_overhaul',
+      title: 'Rewrite the comparison proof section',
+      description: 'Make the evaluation page answer the buyer objection directly.',
+      rationale: 'Grounded in the decision-stage answer gap and weak proof coverage.',
+      pillarId: topicId,
+      pillarName: topicName,
+      targetPageUrl: 'https://example.com/product/comparison',
+      sequence: 1,
+      addressesLenses: ['conversion', 'supply'],
+      brief: {
+        objective: 'Win evaluation-stage trust for the selected persona.',
+        acceptance: [
+          'Lead with a direct answer in the first 100 words',
+          'Add proof points tied to the named persona',
+        ],
+        evidence: {
+          roadmapItemIds: openRoadmapItems.map(item => item.id),
+          decisionCandidateIds: selected?.decisionCandidateIds ?? [],
+          gapIds: selected?.gapIds ?? [],
+        },
+      },
+    },
+  ],
+});
+
+console.log(imported.plan.id, imported.itemIds);
+\`\`\`
+
+If the user has delegated the strategy call and the imported plan is
+ready for the team to use, inspect it and accept it:
+
+\`\`\`ts
+const accepted = await api.post(\`/api/plans/\${imported.plan.id}/accept\`, {});
+
+console.log(accepted.plan.id, accepted.plan.status);
+\`\`\`
+
+Accepting promotes the plan artifact to \`active\`. It still does not
+dispatch work orders; item execution remains on the normal review/status
+path.
+
+Use follow-up authoring endpoints when the user wants refinement:
+
+\`\`\`ts
+await api.patch(\`/api/plans/\${planId}/authoring\`, {
+  narrative: revisedNarrative,
+  mode: 'defend',
+});
+
+await api.patch(\`/api/plans/\${planId}/items/\${itemId}/authoring\`, {
+  title: revisedTitle,
+  rationale: revisedRationale,
+  addressesLenses: ['conversion'],
+});
+
+await api.put(\`/api/plans/\${planId}/items/\${itemId}/brief\`, {
+  brief: revisedBrief,
+});
+\`\`\`
+
+Important boundaries:
+- Direct-authored plans are imported as \`staging\`. Accept them only when
+  the user has delegated that decision or after the user reviews the
+  artifact.
+- Only edit/delete authored items while they are \`todo\` or \`review\`.
+  Once an item is in progress, treat it as execution state.
+- Do not bypass conflict thinking. If you skipped scoped generation
+  because the harness authored the strategy, still read existing plans
+  and explain overlap risks.
+- Do not create work orders directly from the authored plan. Work orders
+  are projected by HG when plan items move through the normal approval path.
+
+### Step 11 \u2014 Generate content briefs when the plan item is ready
 
 For roadmap new-page rows or plan items that need a writer-ready brief,
 use the brief generator only when you can resolve a source question id
@@ -1151,7 +1275,7 @@ If the generator asks for missing inputs, do not invent them. Surface the
 open questions to the user and use the brief chat/context flow to fill
 only those blanks. Then regenerate with the user's guidance.
 
-### Step 11 \u2014 Set expectations
+### Step 12 \u2014 Set expectations
 
 End with reality:
 
@@ -1189,8 +1313,9 @@ End with reality:
 - One bounded scope picked
 - Conflicts reviewed
 - One scoped plan created
-- Scoped generation run
-- Generated items cite the selected evidence spine
+- Scoped generation run, or a hand-authored staging plan imported when
+  the harness can produce the better strategic shape
+- Generated or authored items cite the selected evidence spine
 - Content briefs generated only from resolvable roadmap/plan-item source
   questions, with user guidance captured when needed
 - First execution items are obvious
@@ -1212,6 +1337,11 @@ End with reality:
   include \`topic_roadmap\` in \`includedSignals\`.
 - Don't create a plan that overlaps blocked active work.
 - Don't create work orders from imagination candidates.
+- Don't use the authored-plan API as a shortcut around evidence. It is
+  for writing a better plan artifact into HG after reading HG context,
+  not for making up work.
+- Don't edit in-progress/published/verified plan items through authoring
+  endpoints. Those are execution state.
 - Don't hand-write content briefs when the brief generator has a source
   question. Generate, inspect open questions, collect guidance, then
   regenerate.
@@ -1402,7 +1532,7 @@ var SKILLS = [
   {
     slug: "higrowth-marketing-strategy",
     title: "Marketing strategy chat",
-    description: "Walk a diagnostic, pick a scoped topic or roadmap, build the sprint plan.",
+    description: "Walk a diagnostic, pick a scoped topic or roadmap, generate or hand-author the staging plan.",
     body: MARKETING_STRATEGY
   },
   {
@@ -1647,7 +1777,7 @@ function beginUpdateCheck(currentVersion) {
 // package.json
 var package_default = {
   name: "@higrowth/cli",
-  version: "0.3.4",
+  version: "0.3.5",
   description: "Higrowth CLI \u2014 log in via browser, install Claude Code / Codex skills, manage the MCP connection.",
   type: "module",
   license: "Apache-2.0",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@higrowth/cli",
-  "version": "0.3.4",
+  "version": "0.3.5",
   "description": "Higrowth CLI — log in via browser, install Claude Code / Codex skills, manage the MCP connection.",
   "type": "module",
   "license": "Apache-2.0",