feat(flow-next): project strategy anchor + downstream grounding — 0.40.0

.claude-plugin/marketplace.json

@@ -6,13 +6,13 @@
   },
   "metadata": {
     "description": "Plan-first workflows for Claude Code and Factory Droid. Two plugins: flow-next (recommended, zero-dep, Ralph autonomous mode) and flow (Beads integration).",
-    "version": "0.39.0"
+    "version": "0.40.0"
   },
   "plugins": [
     {
       "name": "flow-next",
-      "description": "Zero-dependency planning + execution with .flow/ task tracking and Ralph autonomous mode (multi-model review gates). Worker subagent per task for context isolation. Includes 21 subagents, 13 commands, 18 skills.",
-      "version": "0.39.0",
+      "description": "Zero-dependency planning + execution with .flow/ task tracking and Ralph autonomous mode (multi-model review gates). Worker subagent per task for context isolation. Includes 21 subagents, 17 commands, 22 skills.",
+      "version": "0.40.0",
       "author": {
         "name": "Gordon Mickel",
         "email": "gordon@mickel.tech",

.flow/epics/fn-39-project-strategy-strategymd-anchor.json

@@ -0,0 +1,20 @@
+{
+  "branch_name": "fn-39-project-strategy-strategymd-anchor",
+  "completion_review_status": "unknown",
+  "completion_reviewed_at": null,
+  "created_at": "2026-05-01T16:31:02.402787Z",
+  "default_impl": null,
+  "default_review": null,
+  "default_sync": null,
+  "depends_on_epics": [
+    "fn-38-project-glossary-decision-records-and"
+  ],
+  "id": "fn-39-project-strategy-strategymd-anchor",
+  "next_task": 1,
+  "plan_review_status": "unknown",
+  "plan_reviewed_at": null,
+  "spec_path": ".flow/specs/fn-39-project-strategy-strategymd-anchor.md",
+  "status": "open",
+  "title": "Project strategy: STRATEGY.md anchor + downstream grounding",
+  "updated_at": "2026-05-01T16:37:07.311315Z"
+}

.flow/specs/fn-30-memory-schema-upgrade-categorized-yaml.md

@@ -85,7 +85,7 @@ applies_when: <one-line — situations this guidance applies to>
 Optional fields (both tracks):
 
 ```yaml
-status: active | stale   # ce-compound-refresh maintenance marker
+status: active | stale   # staleness audit marker (consumed by /flow-next:audit)
 stale_reason: <reason>    # only when status: stale
 stale_date: YYYY-MM-DD    # only when status: stale
 last_updated: YYYY-MM-DD
@@ -165,7 +165,7 @@ flowctl memory list [--track <bug|knowledge>] [--category <cat>] [--json]
 flowctl memory read <entry-id> [--json]
 flowctl memory search <query> [--track <bug|knowledge>] [--category <cat>] [--json]
 flowctl memory migrate [--dry-run] [--yes]
-flowctl memory refresh [--dry-run]              # future: ce-compound-refresh-style maintenance (separate follow-up)
+flowctl memory refresh [--dry-run]              # future: staleness-audit maintenance (separate follow-up)
 ```
 
 Entry ID format: `<track>/<category>/<slug>-<date>` (matches filepath).
@@ -248,7 +248,7 @@ Ralph's receipt contract is unchanged. Memory is a separate surface.
 ## Boundaries
 
 - Not adding vector search (BM25-grep is sufficient for expected corpus size).
-- Not adding ce-compound-refresh drift maintenance in this epic (deferred to follow-up).
+- Not adding staleness-audit drift maintenance in this epic (deferred to follow-up — eventually shipped as `/flow-next:audit`).
 - Not changing the 3-type `--type` API entirely — backward compat is part of the contract.
 - Not auto-running `discoverability-patch` on `memory init` — it's a separate opt-in command.
 - Not introducing a centralized memory registry across projects (memory stays per-project).
@@ -284,6 +284,6 @@ Ralph's receipt contract is unchanged. Memory is a separate surface.
 
 ## Follow-ups (not in this epic)
 
-- `flowctl memory refresh` — MergeFoundry-upstream-style ce-compound-refresh: Keep/Update/Consolidate/Replace/Delete classification against current code; autofix mode marks stale entries
+- `flowctl memory refresh` — staleness audit: Keep/Update/Consolidate/Replace/Delete classification against current code; autofix mode marks stale entries
 - Cross-project memory sharing (if demand surfaces)
 - TUI memory browser (if flow-next-tui matures)

.flow/specs/fn-34-flow-nextaudit-agent-native-memory.md

@@ -127,7 +127,7 @@ After the audit completes, agent verifies CLAUDE.md / AGENTS.md (whichever holds
 
 ## Early proof point
 
-Task fn-34.1 ships the skill files. Validates the workflow shape against upstream's `ce-compound-refresh` (we have a known-working reference). If the skill phases don't compose cleanly with the existing fn-30 memory schema (`status: active|stale`, frontmatter fields, track/category structure), revisit before fn-34.2 (flowctl plumbing).
+Task fn-34.1 ships the skill files. Validates the workflow shape against the agent-native pattern (host agent reads + judges + writes directly, no subprocess LLM dispatch). If the skill phases don't compose cleanly with the existing fn-30 memory schema (`status: active|stale`, frontmatter fields, track/category structure), revisit before fn-34.2 (flowctl plumbing).
 
 ## Risks
 
@@ -145,12 +145,12 @@ Task fn-34.1 ships the skill files. Validates the workflow shape against upstrea
 - **Not** building a Python audit engine. The agent reads + judges directly.
 - **Not** dispatching codex/copilot via subprocess. Host agent is the intelligence.
 - **Not** auditing legacy flat files. Skip with warning; user runs `memory migrate` first.
-- **Not** auto-committing without user awareness. Skill commits in Phase 5 with descriptive message; interactive mode confirms; autofix uses sensible branch defaults (per upstream `ce-compound-refresh` Phase 5 logic).
+- **Not** auto-committing without user awareness. Skill commits in Phase 5 with descriptive message; interactive mode confirms; autofix uses sensible branch defaults.
 - **Not** deleting silently. Delete reserved for unambiguous cases (code gone + problem domain gone). Default to Replace or Consolidate when there's still value to preserve.
 
 ## Decision context
 
-**Why skill-based, not flowctl Python subcommand?** This plugin always runs inside an agentic environment (Claude Code / Codex / Droid). The host agent can read files, run grep, judge relevance, and write updates directly using its own tools. Spawning a second LLM via codex/copilot subprocess is wasteful (cost + latency) and adds machinery (subprocess timeouts, structured-verdict parsers, drift guards) that disappears in the agent-native architecture. Upstream's `ce-compound-refresh` skill is a working reference for this pattern.
+**Why skill-based, not flowctl Python subcommand?** This plugin always runs inside an agentic environment (Claude Code / Codex / Droid). The host agent can read files, run grep, judge relevance, and write updates directly using its own tools. Spawning a second LLM via codex/copilot subprocess is wasteful (cost + latency) and adds machinery (subprocess timeouts, structured-verdict parsers, drift guards) that disappears in the agent-native architecture.
 
 **Why thin flowctl plumbing instead of skill-only?** The skill needs deterministic operations for atomic frontmatter writes (`mark-stale` / `mark-fresh`), schema-validated round-trip, and consistent search filtering. Those are pure persistence concerns where flowctl's existing helpers shine. The split is: flowctl owns "set this field on this entry"; skill owns "should this entry be flagged."