@antoneeo/mkt-agentic-sdlc-skill 0.12.0 → 0.14.0

package/CHANGELOG.md

@@ -1,5 +1,49 @@
 # Changelog
 
+## [0.14.0] - 2026-09-25
+
+### Changed
+- **F-026 revised: a real doubt is asked when it emerges.** The question discipline
+  no longer sends doubts to the deliverable ("Default non-blocking" is gone). A real
+  doubt (a fact the search leaves open, or a choice whose pros and cons do not
+  settle it) is asked before the first write that would embed its answer, grouped,
+  with the pros and cons of each option. A choice that clearly wins the weighing is
+  taken without asking, and the weighing is written next to it — each rejected option
+  stated at its strongest; options that serve different needs, none good enough at
+  both, that nothing the user wrote ranks are a real doubt, however clear the
+  agent's own ranking. Reserved approvals
+  are always asked. A real doubt becomes a declared assumption only in unattended
+  or delegated work. `review.md` makes an unasked doubt a design-review finding; `dispatch.md`
+  tells a subagent to return its real doubts instead of deciding them.
+
+### Fixed
+- **`stale` no longer counts the audit plan against the area that holds it.**
+  Committing a hash mark of `ai_docs/` changed `ai_docs/audit/audit_plan.md` after
+  the recorded commit, so the area went stale again and every re-mark repeated the
+  loop. The plan's own edits are now excluded; any other change in the area still
+  counts.
+
+## [0.13.0] - 2026-09-19
+
+### Added
+- F-057: shared project memory in every lens, no sibling installation required.
+  `index` catalogs original documents; `recall QUERY` searches live metadata.
+  KB integrity is shared; domain ownership and marketing numerical checks remain.
+  Vendored validators now require entry point + sdlc_core.py + knowledge.py.
+
+
+### Fixed
+- **F-056: `stale` no longer reports an area fresh when it cannot evaluate it.** An
+  `audit_plan.md` row whose reference no longer resolves (the commit was amended,
+  rebased or squash-merged away, or the clone is shallow), whose reference is a git
+  hash where git is unusable, or whose reference is unparseable used to print a
+  warning, then `[ok]`, and exit 0. It now prints `[stale]` with the re-mark command
+  and exits 1, so `check` is NOT CLEAN. A reference that still resolves but is no
+  longer an ancestor of HEAD gets a warning before it dangles, and `mark` says to
+  commit its result as a new commit. **Teams that squash- or rebase-merge:** a
+  reference recorded on a feature branch never reaches the integration branch, so
+  re-mark those areas after the merge.
+
 ## [0.12.0] - 2026-09-14
 
 ### Changed

package/README.md

@@ -1,134 +1,150 @@
-# Marketing Agentic SDLC Skill
-
-Evidence-First marketing planning protocol for AI coding agents (Claude Code, Gemini CLI, Google Antigravity, Codex). The sibling of [`@antoneeo/agentic-sdlc-skill`](https://www.npmjs.com/package/@antoneeo/agentic-sdlc-skill), transplanted from software engineering to marketing strategy.
-
-## What it does
-
-Turns an AI agent into a disciplined marketing strategist that produces a professional, professionally-recognized marketing plan (SOSTAC structure) with three engineered guarantees:
-
-1. **Evidence ledger** — every market number is classified FACT / BENCHMARK / ASSUMPTION and carries an `[EV-nn]` reference to its source. No invented numbers.
-2. **Mechanical validator** (`mkt_check.py` + `sdlc_core.py` — the entry point plus the family's shared spine; copy both, or neither) — budget sums (±1%), funnel math recomputed cell by cell (±5%) and the objective→tactic→KPI chain are checked mechanically, not rhetorically: `check`, `validate`, `ledger`, `budget`, `funnel`, `trace`, `index`, plus the spine's `stale`/`mark`/`benefit`/`gate`/`plan`/`orient`/`migrate`. `benefit` reports what the review gates have already caught, beside what the doctrine costs to read; it always exits 0 and carries no verdict.
-3. **Adversarial CMO review** — an independent, fresh-context reviewer attacks the strategy before the user sees it (generic-positioning swap test, untraced claims, orphan tactics).
-
-The agent asks the user only for facts the user uniquely owns (product, price, budget, capacity); everything else — market sizing, competitor analysis, channel benchmarks — is derived from real web research.
-
-## Install
-
-```bash
-npm i -g @antoneeo/mkt-agentic-sdlc-skill
-```
-
-That's it — the skill is copied into every detected AI client automatically
-(the package's `postinstall` runs the installer). Restart the agent to load it.
-
-**If your npm blocks install scripts** (`--ignore-scripts`, some CI/pnpm setups),
-run the installer manually:
-
-```bash
-npx mkt-sdlc-install-skill
-```
-
-> The `mkt-sdlc-install-skill` command is only on your PATH after a **global**
-> (`-g`) install. After a local `npm i`, invoke it via `npx` as above.
-
-Initialize a project:
-
-```bash
-cd my-business-project
-npx mkt-sdlc-init        # creates mkt_docs/ + protocol pointers
-```
-
-It also **wires the SessionStart orientation hook** into `.claude/`, so an agent opening
-the project is handed the reading guide, the generated manifest, the guide router and the
-last handoff before it does anything — instead of only when it remembers to look. That
-wiring used to be a manual step documented in `ENFORCEMENT.md`; being manual, it was
-skipped, and a project could run fully governed with an agent that never met the process.
-
-The hook command names a validator, so where that validator lives decides which file gets
-it: a repo that vendors it gets a repo-relative command in the shared `.claude/settings.json`
-(portable — commit it); otherwise the path is machine-specific and goes to the git-ignored
-`.claude/settings.local.json`, and each teammate runs `init` once. Re-running `init` never
-duplicates the hook, and a hook whose validator no longer resolves is reported as **broken**
-with the correction rather than counted as installed.
-
-## Engagement levels (Rule Zero)
-
-| Level | Scope | Process |
-|---|---|---|
-| E1 Quick | single question / asset feedback | direct answer, sourced numbers |
-| E2 Campaign | one campaign or channel plan | mini-brief + targeted research + campaign doc |
-| E3 Full Plan | complete marketing plan | full SOSTAC workflow, 9 phases, all gates |
-| Research Spike | time-boxed market question | `mkt_docs/spikes/RESEARCH_[topic].md` |
-
-## Several people, one project
-
-The workstream registry (`audit/handoff.md`) is **generated** from one file per open workstream, so two people opening or closing two workstreams on two branches edit two different files and their merge is clean. Row-per-workstream alone was not enough — a file-global `Date:` header defeats row-level ownership — so the header is derived from the sources and no writer touches it. The generated view can still conflict; that conflict is resolved by re-running `index`, never by hand, and `validate` refuses CLEAN until the file matches its sources. The append-only review log gets `merge=union` (a built-in driver, no per-clone configuration). It all works with no VCS at all: it is files and a generator.
-
-## Modes
-
-- **Standalone** — everything on the filesystem under `mkt_docs/`.
-- **Hybrid with devPNT** — plans and strategy artifacts governed as versioned devPNT documents (MKT-VISION, ICP/Personas, Threat Map, Strategy, Tactical Plan, Measurement Plan), with proposal/approval workflow and independent review gates.
-
-The Hybrid seam ships as its own file, `hybrid.md` — the authoritative
-hierarchy and the ownership matrix naming which artifact is mastered where.
-A Standalone engagement never reads it, which is why it is not in the
-operating contract every session loads.
-
-Installing or updating the npm package wires the session-orientation hook
-machine-wide (user-level Claude Code settings; removal is a standing opt-out
-that no update overrides -- ENFORCEMENT.md par.4).
-
-## The family: three lenses, one spine
-
-| Package | Faithful to | Unit of work |
-|---|---|---|
-| [`@antoneeo/agentic-sdlc-skill`](https://www.npmjs.com/package/@antoneeo/agentic-sdlc-skill) | this repository's code | feature |
-| [`@antoneeo/kb-agentic-skill`](https://www.npmjs.com/package/@antoneeo/kb-agentic-skill) | the documents you supply | topic |
-| `@antoneeo/mkt-agentic-sdlc-skill` (this one) | market evidence | engagement |
-
-Triage, the Vision Gate, the review gates, the guide router, question discipline and the validator spine are byte-identical across the three; only the fidelity discipline and the vocabulary change. When two live in the same project, `routing.md` decides which lens owns a given piece of work — with the market-facing override: anything whose purpose is to persuade the market is this lens's, whatever its source.
-
-## Which model to run it on
-
-The skill names **capability tiers**, never providers — a model name in doctrine
-rots at the next release. The binding is yours to make, and the rule is one line:
-
-> **A session's floor is the highest floor among the roles it performs itself.**
-
-Authoring a governed artifact — the vision, the analysis, the use cases, the
-threat model — is a **deep-tier** role: its output is judgement, and nothing
-downstream scores it. So a session that will DESIGN wants your strongest model.
-A session that only executes an already-approved plan, or does small maintenance,
-can sit a tier lower. The cheapest tier is the wrong choice for the main session
-whatever the task, because the failure there is not a wrong answer — it is
-**silently not applying the process**: a triage never run, a router verdict
-declared without the lookup, a gate nobody noticed. That failure is invisible to
-every check in here.
-
-**The reviewer's tier is not automatically yours.** On some clients a subagent
-inherits the session's model; on others it takes one from its own definition, so
-a strong session can be reviewed by a weak one — and a weak session can buy a
-strong review. Set it deliberately; the
-`model` column in the review log is where the choice becomes visible.
-
-**Avoid one combination**: authoring below the floor AND reviewing below the floor
-on the same unit. One disclosed weakness is a disclosed weakness; two is an
-artifact nobody competent ever read. Where your client offers nothing better, the
-review still runs and both facts are recorded — a disclosed worst case beats
-skipping the review.
-
-## License
-
-Apache-2.0 — the full terms are in the `LICENSE` file, the attribution in `NOTICE`. Copyright 2026 Antonio Pinto.
-
-If you redistribute this skill, or a version you modified, keep `LICENSE` and `NOTICE` with it.
-
-Using the skill in your own project carries no obligation: the documents it creates or templates there are yours, and so is a copy of the validator and its tests placed in that project to check its own documents.
-
-Versions up to 0.11.0 were released under the MIT license and remain available under it.
-
-If you use the skill in commercial work, a mention on your product page or website is appreciated. It is a request, not a condition of the license. A ready-made badge:
-
-```markdown
-[![Made with mkt-agentic-sdlc](https://img.shields.io/badge/made%20with-mkt--agentic--sdlc-blue)](https://www.npmjs.com/package/@antoneeo/mkt-agentic-sdlc-skill)
-```
+# Marketing Agentic SDLC Skill
+
+## Shared project memory
+
+All three lenses include project memory by default; install the lens you need,
+not a second skill just for recall. `index` registers guides, decisions and plans
+in the docs root's `memory/INDEX.md`, linking originals without copying them.
+`recall "onboarding"` finds related metadata across domains; optional
+`topics: [onboarding]` links documents by subject. Read the originals for authority,
+status and evidence: discovery is not approval or proof of implementation.
+
+Registration happens at `index`/documentation closure, not through a background
+watcher. Existing projects acquire the catalog on their next `index`; `recall`
+also sees live metadata. The KB lens remains the specialist for ingestion and
+taxonomy. Marketing retains its numerical validators. See the skill's `memory.md`.
+Vendoring requires all three files: the entry point, `sdlc_core.py`, `knowledge.py`.
+
+
+Evidence-First marketing planning protocol for AI coding agents (Claude Code, Gemini CLI, Google Antigravity, Codex). The sibling of [`@antoneeo/agentic-sdlc-skill`](https://www.npmjs.com/package/@antoneeo/agentic-sdlc-skill), transplanted from software engineering to marketing strategy.
+
+## What it does
+
+Turns an AI agent into a disciplined marketing strategist that produces a professional, professionally-recognized marketing plan (SOSTAC structure) with three engineered guarantees:
+
+1. **Evidence ledger** — every market number is classified FACT / BENCHMARK / ASSUMPTION and carries an `[EV-nn]` reference to its source. No invented numbers.
+2. **Mechanical validator** (`mkt_check.py` + `sdlc_core.py` + `knowledge.py` — entry point, shared spine and memory; copy all three) — budget sums (±1%), funnel math recomputed cell by cell (±5%) and the objective→tactic→KPI chain are checked mechanically, not rhetorically: `check`, `validate`, `ledger`, `budget`, `funnel`, `trace`, `index`, plus the spine's `stale`/`mark`/`benefit`/`gate`/`plan`/`orient`/`migrate`. `benefit` reports what the review gates have already caught, beside what the doctrine costs to read; it always exits 0 and carries no verdict.
+3. **Adversarial CMO review** — an independent, fresh-context reviewer attacks the strategy before the user sees it (generic-positioning swap test, untraced claims, orphan tactics).
+
+The agent asks the user only for facts the user uniquely owns (product, price, budget, capacity); everything else — market sizing, competitor analysis, channel benchmarks — is derived from real web research.
+
+## Install
+
+```bash
+npm i -g @antoneeo/mkt-agentic-sdlc-skill
+```
+
+That's it — the skill is copied into every detected AI client automatically
+(the package's `postinstall` runs the installer). Restart the agent to load it.
+
+**If your npm blocks install scripts** (`--ignore-scripts`, some CI/pnpm setups),
+run the installer manually:
+
+```bash
+npx mkt-sdlc-install-skill
+```
+
+> The `mkt-sdlc-install-skill` command is only on your PATH after a **global**
+> (`-g`) install. After a local `npm i`, invoke it via `npx` as above.
+
+Initialize a project:
+
+```bash
+cd my-business-project
+npx mkt-sdlc-init        # creates mkt_docs/ + protocol pointers
+```
+
+It also **wires the SessionStart orientation hook** into `.claude/`, so an agent opening
+the project is handed the reading guide, the generated manifest, the guide router and the
+last handoff before it does anything — instead of only when it remembers to look. That
+wiring used to be a manual step documented in `ENFORCEMENT.md`; being manual, it was
+skipped, and a project could run fully governed with an agent that never met the process.
+
+The hook command names a validator, so where that validator lives decides which file gets
+it: a repo that vendors it gets a repo-relative command in the shared `.claude/settings.json`
+(portable — commit it); otherwise the path is machine-specific and goes to the git-ignored
+`.claude/settings.local.json`, and each teammate runs `init` once. Re-running `init` never
+duplicates the hook, and a hook whose validator no longer resolves is reported as **broken**
+with the correction rather than counted as installed.
+
+## Engagement levels (Rule Zero)
+
+| Level | Scope | Process |
+|---|---|---|
+| E1 Quick | single question / asset feedback | direct answer, sourced numbers |
+| E2 Campaign | one campaign or channel plan | mini-brief + targeted research + campaign doc |
+| E3 Full Plan | complete marketing plan | full SOSTAC workflow, 9 phases, all gates |
+| Research Spike | time-boxed market question | `mkt_docs/spikes/RESEARCH_[topic].md` |
+
+## Several people, one project
+
+The workstream registry (`audit/handoff.md`) is **generated** from one file per open workstream, so two people opening or closing two workstreams on two branches edit two different files and their merge is clean. Row-per-workstream alone was not enough — a file-global `Date:` header defeats row-level ownership — so the header is derived from the sources and no writer touches it. The generated view can still conflict; that conflict is resolved by re-running `index`, never by hand, and `validate` refuses CLEAN until the file matches its sources. The append-only review log gets `merge=union` (a built-in driver, no per-clone configuration). It all works with no VCS at all: it is files and a generator.
+
+## Modes
+
+- **Standalone** — everything on the filesystem under `mkt_docs/`.
+- **Hybrid with devPNT** — plans and strategy artifacts governed as versioned devPNT documents (MKT-VISION, ICP/Personas, Threat Map, Strategy, Tactical Plan, Measurement Plan), with proposal/approval workflow and independent review gates.
+
+The Hybrid seam ships as its own file, `hybrid.md` — the authoritative
+hierarchy and the ownership matrix naming which artifact is mastered where.
+A Standalone engagement never reads it, which is why it is not in the
+operating contract every session loads.
+
+Installing or updating the npm package wires the session-orientation hook
+machine-wide (user-level Claude Code settings; removal is a standing opt-out
+that no update overrides -- ENFORCEMENT.md par.4).
+
+## The family: three lenses, one spine
+
+| Package | Faithful to | Unit of work |
+|---|---|---|
+| [`@antoneeo/agentic-sdlc-skill`](https://www.npmjs.com/package/@antoneeo/agentic-sdlc-skill) | this repository's code | feature |
+| [`@antoneeo/kb-agentic-skill`](https://www.npmjs.com/package/@antoneeo/kb-agentic-skill) | the documents you supply | topic |
+| `@antoneeo/mkt-agentic-sdlc-skill` (this one) | market evidence | engagement |
+
+Triage, the Vision Gate, the review gates, the guide router and the validator spine are byte-identical across the three, and the question discipline is the same rule restated in each lens's vocabulary; only the fidelity discipline and the vocabulary change. When two live in the same project, `routing.md` decides which lens owns a given piece of work — with the market-facing override: anything whose purpose is to persuade the market is this lens's, whatever its source.
+
+## Which model to run it on
+
+The skill names **capability tiers**, never providers — a model name in doctrine
+rots at the next release. The binding is yours to make, and the rule is one line:
+
+> **A session's floor is the highest floor among the roles it performs itself.**
+
+Authoring a governed artifact — the vision, the analysis, the use cases, the
+threat model — is a **deep-tier** role: its output is judgement, and nothing
+downstream scores it. So a session that will DESIGN wants your strongest model.
+A session that only executes an already-approved plan, or does small maintenance,
+can sit a tier lower. The cheapest tier is the wrong choice for the main session
+whatever the task, because the failure there is not a wrong answer — it is
+**silently not applying the process**: a triage never run, a router verdict
+declared without the lookup, a gate nobody noticed. That failure is invisible to
+every check in here.
+
+**The reviewer's tier is not automatically yours.** On some clients a subagent
+inherits the session's model; on others it takes one from its own definition, so
+a strong session can be reviewed by a weak one — and a weak session can buy a
+strong review. Set it deliberately; the
+`model` column in the review log is where the choice becomes visible.
+
+**Avoid one combination**: authoring below the floor AND reviewing below the floor
+on the same unit. One disclosed weakness is a disclosed weakness; two is an
+artifact nobody competent ever read. Where your client offers nothing better, the
+review still runs and both facts are recorded — a disclosed worst case beats
+skipping the review.
+
+## License
+
+Apache-2.0 — the full terms are in the `LICENSE` file, the attribution in `NOTICE`. Copyright 2026 Antonio Pinto.
+
+If you redistribute this skill, or a version you modified, keep `LICENSE` and `NOTICE` with it.
+
+Using the skill in your own project carries no obligation: the documents it creates or templates there are yours, and so is a copy of the validator and its tests placed in that project to check its own documents.
+
+Versions up to 0.11.0 were released under the MIT license and remain available under it.
+
+If you use the skill in commercial work, a mention on your product page or website is appreciated. It is a request, not a condition of the license. A ready-made badge:
+
+```markdown
+[![Made with mkt-agentic-sdlc](https://img.shields.io/badge/made%20with-mkt--agentic--sdlc-blue)](https://www.npmjs.com/package/@antoneeo/mkt-agentic-sdlc-skill)
+```

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "mkt-agentic-sdlc",
-  "version": "0.12.0",
+  "version": "0.14.0",
   "description": "Evidence-First marketing planning protocol with engagement triage, SOSTAC workflow, evidence ledger and optional devPNT integration.",
   "author": "Antonio Pinto (https://github.com/Antoneeo)"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@antoneeo/mkt-agentic-sdlc-skill",
-  "version": "0.12.0",
+  "version": "0.14.0",
   "description": "Evidence-First marketing planning protocol for Claude Code, Gemini CLI, Google Antigravity and Codex: engagement triage, SOSTAC workflow, evidence ledger, mechanical validator and optional devPNT integration.",
   "keywords": [
     "claude-code",
@@ -33,6 +33,8 @@
     "skills/mkt-agentic-sdlc/templates.md",
     "skills/mkt-agentic-sdlc/review.md",
     "skills/mkt-agentic-sdlc/scripts/sdlc_core.py",
+    "skills/mkt-agentic-sdlc/scripts/knowledge.py",
+    "skills/mkt-agentic-sdlc/memory.md",
     "skills/mkt-agentic-sdlc/routing.md",
     "skills/mkt-agentic-sdlc/guides.md",
     "skills/mkt-agentic-sdlc/vision.md",

package/scripts/init.js

@@ -194,26 +194,16 @@ in the skill's \`routing.md\`: it decides which lens's method and validation rul
 that unit. L1 never reaches it. Never refer to a document whose meaning differs by lens
 ("threat model", "vision", \`principles.md\`, \`handoff.md\`) by its bare name.
 
-${protocolPreexisting ? `**Merge step owed.** The always-on protocol pointer of this project (\`CLAUDE.md\` /
-\`GEMINI.md\` / \`AGENTS.md\` / \`.cursorrules\`) was written by another lens's init and
-carries ITS triage ladder. This init did not overwrite it. Add the marketing lens's ladder
-to that file by hand — the pointer below — so both are always loaded.
-
-## Rule Zero — Triage every request (marketing lens)
-- E1 Question: one answer from the existing plan, no document written.
-- E2 Campaign: a single campaign or channel, on an approved strategy.
-- E3 Full engagement: the nine-phase SOSTAC workflow, evidence ledger and all
-  three validator gates.
-` : `The always-on protocol pointer for the marketing lens was created by this init. When you
-install another lens over this project, its init will leave its own ladder here for you
-to merge.
-`}
+Select the owning lens by the unit's purpose, then apply only its risk scale.
+The project's always-on pointer stays intact: consult the selected skill rather than
+merging multiple mandatory ladders. All lenses already carry shared project memory
+(\`memory.md\`); another installation is not needed for cross-domain recall.
 This file is NOT auto-loaded by any client: it is a note for you, deliberately additive.
-Delete it once the merge is done.
+Delete this note once the routing pointer is integrated.
 `, 'multi-lens routing note');
   if (wrote && protocolPreexisting) {
     console.log('   ⚠️  A protocol pointer already existed and was NOT overwritten.');
-    console.log(`       Merge the ${SELF_LENS}-lens ladder from AGENTIC_MULTI_LENS.md into it by hand.`);
+    console.log('       Integrate the routing pointer from AGENTIC_MULTI_LENS.md; keep one risk scale per unit.');
   }
 }
 

package/skills/mkt-agentic-sdlc/ENFORCEMENT.md

@@ -14,17 +14,17 @@ python "<skill_dir>/scripts/mkt_check.py" check
 
 ## 2. Check in CI (recommended for teams)
 
-Copy **both** validator files into the repository — `scripts/mkt_check.py` (the entry point) **and** `scripts/sdlc_core.py` (the shared core it imports) — keeping them side by side, e.g. `tools/mkt_check.py` + `tools/sdlc_core.py`. Then add to the pipeline:
+Copy all three validator files into the repository: `scripts/mkt_check.py`, `scripts/sdlc_core.py`, and `scripts/knowledge.py`, keeping them side by side. Then add to the pipeline:
 
 ```
 python tools/mkt_check.py validate --strict
 ```
 
-The validator ships as two files: the core carries the behaviour and is identical in every distribution of the family, the entry point names the domain. Copying only `mkt_check.py` fails immediately with a message saying so — loudly, never as a silently green pipeline. (Copying `sdlc_core.py` alone also works: `python tools/sdlc_core.py validate --strict` behaves identically, defaulting to the code domain.)
+The validator ships as **three files**: the domain entry point, `sdlc_core.py` and `knowledge.py`. Keep all three together. The core alone still runs but omits shared-memory/KB checks and domain-specific overlays; it is not an equivalent CI gate. `check` includes the knowledge surface when present.
 
 Effect: an unregenerated index, invalid frontmatter, a missing security section or incoherent states **block the pipeline** instead of relying on the agent's memory. `--strict` also fails on warnings and on a missing `ai_docs/`, so a wrong working directory cannot produce a green pipeline. This works because documents travel in the same PR as the code (Phase 5 rule).
 
-Note: the copy in the repo is the authoritative one for CI; update it when you update the skill — both files, together.
+Note: the copy in the repo is the authoritative one for CI; update it when you update the skill — all three files, together.
 
 **Projects whose docs root is not `ai_docs/`.** Pass `--docs-dir <name>` (e.g. `--docs-dir mkt_docs`) on any subcommand, or set `AGENTIC_SDLC_DOCS_DIR`. Without either, the validator walks up from the working directory and takes the nearest root it recognizes. If it finds two side by side — the shape of a half-finished migration — it refuses and names both rather than validating half a project and printing a verdict. `ai_docs/` remains the default and the recommended root: the parameter exists so a legacy tree can be read and migrated, not so a second one can be kept.
 
@@ -155,7 +155,7 @@ Gemini CLI — wire the same command into its startup-hook mechanism if present;
 **Usage notes:**
 - The hook assumes the working directory is the project root (standard Claude Code hook behavior); it also accepts `--root <path>`.
 - **Hybrid/devPNT projects**: add `--hybrid` — the hook then appends a one-line pointer to run `devpnt_mcp_get_bootstrap` for the Master Plan / Knowledge Layer and does not replicate them; the filesystem orientation (router + handoff + README) still emits.
-- Like the CI gate (§2), if you copied the validator into the repo, the hook references that copy — keep both files current when you update the skill.
+- Like the CI gate (§2), if you copied the validator into the repo, the hook references that copy — keep all three files current when you update the skill.
 
 ### Per-turn reminder: `remind` (UserPromptSubmit -- wired by default)
 
@@ -215,7 +215,7 @@ It aggregates the test files (`test_plan.py` + `test_session_start.py` + `test_s
 
 **Optional CI** (same shape as §2, not mandatory): add a `run:` step invoking the `unittest discover` command above.
 
-**T10 note:** if you copied the validator (both files) and the `test_*.py` battery into the repo for CI, that copy is authoritative — keep it current when you update the skill.
+**T10 note:** if you copied the validator (all three files) and the `test_*.py` battery into the repo for CI, that copy is authoritative — keep it current when you update the skill.
 
 ## `benefit` is a report, never a CI gate
 

package/skills/mkt-agentic-sdlc/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mkt-agentic-sdlc
-version: 0.12.0
+version: 0.14.0
 description: Evidence-First marketing planning protocol with engagement triage, SOSTAC workflow, evidence ledger, adversarial CMO review, a complete Standalone mode and optional symbiosis with devPNT. Use for marketing plans, go-to-market strategy, campaign planning and market research.
 author: Antonio Pinto (https://github.com/Antoneeo)
 copyright: (c) 2026 Antonio Pinto
@@ -17,7 +17,7 @@ Support files in the skill directory:
 - `research.md`: the research playbook and the evidence ledger discipline.
 - `templates.md`: templates for every artifact and deliverable.
 - `review.md`: the family's shared review discipline (independence ladder, rounds, log). The marketing-specific attack surface — swap test, untraced numbers, orphan tactics, missing kill/scale — lives in `frameworks.md`'s falsification rules; the adversarial CMO review applies them through `review.md`'s procedure.
-- `scripts/mkt_check.py` + `scripts/sdlc_core.py`: the mechanical validator (`check`, `validate`, `ledger`, `benefit`, `budget`, `funnel`, `trace`, `index`, plus the spine's `stale`/`mark`/`gate`/`orient`/`plan`/`migrate`). Two files: the core is the family's shared spine, the entry point is this domain's overlay. Copy both, or neither.
+- `scripts/mkt_check.py` + `scripts/sdlc_core.py`: the mechanical validator (`check`, `validate`, `ledger`, `benefit`, `budget`, `funnel`, `trace`, `index`, plus the spine's `stale`/`mark`/`gate`/`orient`/`plan`/`migrate`).  Keep the entry point, `scripts/sdlc_core.py` and `scripts/knowledge.py` together; the last supplies common memory and KB integrity.
 - `hybrid.md`: the devPNT seam — the authoritative hierarchy, the ownership matrix (which artifact is mastered where), and the Hybrid rules. Read it when the `devpnt_*` tools point at this project; a Standalone engagement never needs it.
 - `ENFORCEMENT.md`: optional setup for CI and hooks.
 
@@ -40,6 +40,14 @@ No process guarantees market success, and this skill never claims one. What it g
 
 If a strategic choice looks obvious but you cannot trace it to evidence, research first.
 
+## Shared project memory
+
+Project memory is available by default, independently of installed sibling lenses.
+Read `memory.md` for the common consult/capture contract during orientation and
+closure. Use `recall` for cross-domain discovery; `index` registers original guides,
+plans and decisions without copying them. One owner still governs each unit.
+The validator now ships as three files: entry point, `sdlc_core.py`, `knowledge.py`.
+
 ## Rule Zero: Triage
 
 
@@ -57,7 +65,7 @@ Always classify the request before choosing the process. Declare the chosen leve
 | **Research Spike** | Time-boxed market question that reduces uncertainty ("is there demand for X in market Y?") | Outcome in `mkt_docs/spikes/RESEARCH_[topic].md`. Ledger discipline applies. For strategy decisions, feed into E2/E3. |
 
 Cross-cutting rules:
-- Every question to the user passes the legality test of the question discipline (`elicitation.md`): searched first with the search named, and the blocked decision named. The waves are where asking is planned; outside them the test gates each ask.
+- A real doubt is asked when it emerges, before its answer is written; every question passes the legality test of the question discipline (`elicitation.md`): searched first with the search named, and the blocked decision named. The waves are where asking is planned; outside them the test gates each ask.
 - Anything touching pricing strategy, brand repositioning, or a new market entry is never E1: those decisions cascade.
 - If a bigger scope emerges during E1/E2 work (e.g. the campaign reveals there is no positioning), stop, reclassify and declare it.
 - When in doubt, pick the higher level.

package/skills/mkt-agentic-sdlc/dispatch.md

@@ -26,7 +26,11 @@ without an E-ISP.
    - `sdlc_check.py plan brief PLAN_[feature].md --task <id>` — prints the
      task block, the `produces` of prior-order tasks (interfaces), and
      `guides` pointers (paths, never pasted content) to stdout.
-   - Spawn the subagent with that brief as its entire context window.
+   - Spawn the subagent with that brief plus the return-doubts line as its
+     entire context window. The line: "An open point whose answer changes the
+     work is not yours to decide: return it in your final output with what you
+     searched." The orchestrator treats them as its own candidate doubts
+     (`elicitation.md` §When a doubt emerges).
    - Run `task.verify` out of band (the orchestrator executes it — the
      validator only ever prints it, never runs it) plus the one-shot review
      below.