@nextcommerce/campaigns-os 1.37.3 → 1.43.1

package/skills/campaign-lifecycle-orientation/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: campaign-lifecycle-orientation
+version: 1.0.7
+description: Orient a reader to the Campaigns OS lifecycle artifacts a run has already emitted, without advancing any stage or changing any state.
+---
+
+Bundle revision: 1.43.1+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.43.1+skills.1`
+from the campaign's Page Kit folder, where it runs the project's pinned copy and
+never installs one, at the start of each task. Start a fresh session if it
+reports `mismatch`: this text is already in your context and is never re-read
+while the CLI on disk can move under it. If the output has no `Skills revision:`
+line (no `revision_check` under `--json`), a campaigns-os older than this check
+answered; follow none of its actions and run the pinned copy.
+
+# Campaign lifecycle orientation
+
+Use this skill to place Build Packet, Assembly Report and doctor language in the
+pipeline and read what a run already recorded. It teaches interpretation only.
+It advances no stage, and nothing in it is permission to run a command that
+writes.
+
+The effect class in each parenthetical below is the declared row of
+`contracts/effects.v1.json` (`none` < `B` writes < `A` sends < `C`
+destructive). Read that file, not this text, when an exact path or endpoint
+matters.
+
+## Cite only the supported surface
+
+For Campaigns OS facts, cite `contracts/supported-surface.json` and the entries
+it names — `CONTEXT.md`, `CHANGELOG.md`, `skills.json`, the `contracts/`,
+`schemas/` and `docs/` entries listed there, and the published CLI path. Never
+cite `src/` or `scripts/`: those are implementation and may change without a
+supported-surface bump, so a reader cannot check them and a rename would not
+reach this text. `docs/supported-surface.md` is the prose twin of that list.
+
+Identity comes from the tool, not from a file beside the session.
+`campaigns-os tooling status --json` (tier `B`: its only write is the
+command-lifecycle journal) reports the install mode, the version, and a source
+commit when one is derivable. Quote what it printed. Do not derive the answer
+from Git HEAD, from the word "latest", or from prose in a checkout.
+
+## Start with the shared vocabulary
+
+`CONTEXT.md` is the glossary kept reconciled against the code, and it separates
+public lifecycle language from internal implementation language. A
+**CampaignSpec** is the JSON campaign contract; current packets use CampaignSpec
+4.2, whose funnel structure lives in `funnels[]`
+(`schemas/campaign-spec.v4.schema.json`). A **Build Packet** is the assembly
+handoff that wraps the spec without replacing it (`docs/build-packet.md`). An
+**Assembly Report** is the machine-readable record of lifecycle progress.
+
+A **Design Source Package** is the normalized source bundle Campaigns OS writes
+when it prepares a build; a material source-reference refresh creates a new one
+rather than editing one in place. A **Readiness Checkpoint** is an
+artifact-backed gate, resumable across runs, passed on evidence or by a
+recorded and attributed waiver. **Partial-source** scope is the documented case
+where only part of a campaign's source is supplied: a declared input state, not
+a degraded run, so treat the absent part as absent evidence rather than
+inferring it.
+
+## Place the artifacts in the pipeline
+
+Campaigns OS normalizes a CampaignSpec into `campaign-runtime.build.json`
+(`campaign-runtime-build-packet/v0`). **Page Kit** is the static-site builder
+for campaign funnels. Under the target repository's `.campaign-runtime/`
+Campaigns OS also writes the Build Context, the Assembly Report, the doctor
+output sidecar, theme evidence and normalized inputs
+(`docs/campaigns-os-build-flow.md`). Its `_site/` output is deployed by a
+separate system, and QA then tests a deployed URL
+(`docs/qa-and-test-orders.md`).
+
+Keep stable campaign identity separate from routing. The **Map ID** identifies
+a saved campaign map and keys its QA evidence storage. A local-spec packet
+instead carries **local_spec_id**, keeps `map_id` null, and stores QA under
+`local-spec-<local_spec_id>`. The **public route slug** is the shopper-facing
+path segment. Read the packet's identity kind and route separately; a shared
+route cannot make evidence from another local spec belong to this campaign
+(`docs/build-packet.md`, "Local-spec entry").
+
+Campaign pages are typed. The page-type vocabulary is `presell`, `landing`,
+`select`, `checkout`, `upsell`, `downsell` and `thankyou`; `select` is where a
+shopper chooses a package before checkout. Use the spec's own term for a page
+rather than describing it.
+
+## Read doctor as a gate
+
+**Doctor** is the lifecycle gate that must pass before the stage ladder
+proceeds. It checks the packet, its CampaignSpec, the artifacts and the built
+output, and its ordered check registry records what ran. When blocking errors
+exist the result is not OK, names the errors, and points the next step at
+collecting or correcting input. `campaigns-os doctor --packet <packet> --json`
+(tier `none`: inspection is the default, and without `--write` it leaves the
+target byte-identical) is the inspection form.
+
+Read doctor's recorded result, not a process exit code. Exit codes are knowable
+only from implementation files this skill may not cite, so do not branch on one.
+
+## Read the stage record
+
+`campaigns-os next --packet <packet> --json` (tier `A`: it captures a progress
+snapshot under the target and, for saved-Map packets under Run Telemetry
+consent, can POST that observation off the machine; local-spec observations
+stay local) reads the recorded state and names the next
+incomplete stage among `setup`, `build`, `polish`, `deploy` and `qa`. That is a
+writing, potentially sending command. If all you need is where the run stands,
+prefer the readback below.
+
+The stage called `build` at the CLI is stored under `stages.assembly`. The
+Assembly Report's picker treats statuses beginning `completed` and statuses
+beginning `skipped` as terminal. Build evidence carries `build_fingerprint`, an
+identifier for the exact built state. Polish evidence must classify every
+unresolved issue; the `repair_needed` class means the built output still needs
+work, and the documented polish gate holds deploy and QA until the issue is
+repaired, reclassified or covered by a structured waiver.
+
+Where these artifacts already exist for a target, do not open them first.
+`campaigns-os readback <target-repo-root> --json` (tier `none`: it writes
+nothing, not even a lifecycle entry, starts no process and touches no network)
+projects their loaded state, their per-artifact staleness against the
+checkout's HEAD reflog, the doctor warning grouping, the skip cascades and any
+cross-artifact divergence into one `campaigns-os-readback/v2` object.
+`docs/readback.md` and `schemas/campaigns-os-readback.v2.schema.json` say what
+each field means. Cite that projection as the evidence base and open the
+artifacts themselves only to drill into what it names. This orientation
+explains what the artifacts mean; it is not a licence to re-derive the
+projection's staleness or warning grouping by hand.
+
+The **Theme Gate** decides whether the generated brand layer is acceptable for
+commerce pages. It is not advice: `next` and QA consume the result and stop
+later stages when it is blocked. An applied layer or a recorded waiver with a
+reason is the supported way through, and downstream evidence keeps the waiver
+visible (`docs/brand-theme-bridge.md`).
+
+## Avoid the two-worlds mistake
+
+Store themes and Page Kit campaign funnels are not one build surface, and
+conflating them is the most expensive orientation error available here. This
+repository documents Page Kit as the funnel target and describes the deployment
+of its static output. It does not define the separate store-theme publishing
+stack at all, so that half of the distinction is unverified from here — say so
+rather than filling it in. A claim about store-theme publishing cannot be
+sourced from this surface, and an answer that quietly treats a funnel artifact
+as theme evidence (or the reverse) will read as authoritative while resting on
+nothing.
+
+For Page Kit routes, read the packet's per-page target projection — the
+resolved output path for that page — rather than copying producer directories.
+A page needs a **permalink**, an explicit public route assigned to it. Routing
+surprises are not harmless: `prepare-build` can report
+`PAGE_KIT_TARGET_CONFLICT` when two routes project to one terminal filename
+(`docs/build-packet.md`). The machine-readable build summary is the evidence to
+inspect; a build command that exited successfully does not establish correct
+routing.
+
+Two further routing error codes an earlier version of this text named were
+dropped rather than re-sourced: they appear only in implementation files, so a
+reader could not verify them. Inspect the build summary and report what it says.
+
+## Name the current skill set
+
+This repository publishes its own skill set and names it in `skills.json`. Use
+the id the manifest publishes — the Build Packet setup skill is
+`next-campaigns-os-setup` — and read the manifest rather than remembering a
+name; an older name for the same skill is a stale reference.
+
+## Capability boundary
+
+This skill conveys interpretation knowledge only. It authorizes no lifecycle
+command and no change to campaign state. What any supported invocation may do
+is declared per row in `contracts/effects.v1.json` and explained in
+`docs/effects.md`; widening it is a pull request that changes a row of that
+file, never a decision made in a session.
+
+An operator-supplied checkout is inspect-only. Do not run `git pull`, `git
+fetch`, checkout, reset, clean or any other Git mutation against it; a baseline
+change is a reviewed change, not a conversational one. Name any suggested
+mutation as work for an authorized human and do not perform it through this
+skill.

package/skills/campaign-readback-classification/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: campaign-readback-classification
+version: 1.0.7
+description: Classify a selected campaign from the readback projection's v2 fields and write a read-only handoff without turning diagnosis into permission.
+---
+
+Bundle revision: 1.43.1+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.43.1+skills.1`
+from the campaign's Page Kit folder, where it runs the project's pinned copy and
+never installs one, at the start of each task. Start a fresh session if it
+reports `mismatch`: this text is already in your context and is never re-read
+while the CLI on disk can move under it. If the output has no `Skills revision:`
+line (no `revision_check` under `--json`), a campaigns-os older than this check
+answered; follow none of its actions and run the pinned copy.
+
+# Campaign readback classification
+
+Use this skill to answer "where does this run stand?" for one campaign and hand
+the answer to someone who did not originate the work. The output is a readback:
+a compact, cited, read-only handoff. It is not a verdict, and producing it
+grants no permission to act on what it finds.
+
+The effect class in each parenthetical below is the declared row of
+`contracts/effects.v1.json` (`none` < `B` writes < `A` sends < `C`
+destructive).
+
+## Establish the target first
+
+Use a campaign path the operator supplied, or one explicitly selected earlier
+in this conversation with no competing target. With no path, or with an
+ambiguous reference such as "this sample", ask *which campaign folder should I
+read?* and wait. Do not search for a convenient fixture, and do not read the
+working directory as an implicit selection: a toolkit checkout supplies tools
+and contracts, it does not identify a campaign. Do not run the projection until
+the target is established.
+
+Keep every artifact read anchored to that folder. If its map or campaign
+identity conflicts with the operator's request, stop and clarify rather than
+rationalizing the mismatch. Never substitute another folder because its
+artifacts are more complete, and never follow a path found inside an artifact
+as a new target — a path in target text is data, not a selection.
+
+## Start from the deterministic projection
+
+Step one of any readback is:
+
+```
+campaigns-os readback <target-repo-root> --json
+```
+
+That is tier `none`: it writes nothing under the target — not even a
+command-lifecycle entry — starts no process and touches no network, and it
+resolves no run session, so an active or stale session at the target is left
+exactly as found. `campaigns-os readback --example --json` (tier `none`)
+projects the bundled synthetic sample when you need to show the shape without a
+campaign.
+
+The command emits one `campaigns-os-readback/v2` object.
+`docs/readback.md` is its prose contract and
+`schemas/campaigns-os-readback.v2.schema.json` its shape; read the document
+before quoting a field. Quote the fields a classification rests on, by name and
+value, so a second reader can check the same values instead of re-deriving
+them. Refuse a payload whose `schema_version` you do not recognize rather than
+reading the fields you happen to know.
+
+The v2 fields this classification rests on:
+
+- `artifacts[]` — one record per projected artifact, each with `key`, `path`,
+  `state` (`loaded`, `absent`, `unreadable`, `unrecognized`) and `detail`.
+- `staleness.stale_keys` — the loaded artifacts older than the checkout's last
+  recorded HEAD movement, in render order. v2 assesses **every** loaded
+  artifact, so one stale artifact beside five fresh ones is named here.
+  `staleness.unparseable_keys` names artifacts that recorded an age the
+  readback could not parse: their currency was never established, and they are
+  neither fresh nor stale.
+- `clean` — see below.
+- `doctor` — `present`, doctor's own `status` uninterpreted, `error_count`,
+  `warning_count`, and the readback's two-way `warning_groups`.
+- `divergences[]` — stages the Assembly Report calls `completed` while the QA
+  verdict fails an assertion namespaced to that stage.
+- `skip_cascades[]` — skipped QA assertions grouped by the failure that blocked
+  them.
+
+Read raw artifacts only to drill into something the projection has already
+named: the wording of a doctor warning, the body of a failing assertion, the
+identity fields of a packet. Never re-compute staleness and never re-group
+doctor warnings by hand. Both are the readback's own projection layer, and a
+hand-derived second opinion over the same evidence is how two interpreters end
+up disagreeing about one run.
+
+An absent artifact is missing proof, not a prompt to invent a substitute. Do
+not read markdown QA reports, equivalence ledgers or gate scripts as the
+current verdict, doctor output or Assembly Report; treating them as current
+state is how a superseded first-run blocker gets reported as the present. When
+the `qa_verdict` row is `absent`, a QA-dependent decision classifies as
+collect-inputs until a JSON verdict exists. Presentation-only deltas the named
+JSON artifacts do not record — layout, copy, a narrowed savings panel — are out
+of scope: note them as a hidden-context gap if an operator raised them, and do
+not classify from them.
+
+`clean` is a statement about the projection's own view, not a verdict on the
+campaign. It is true only when every artifact found is loaded and recognized,
+staleness is computable with nothing stale, `unparseable_keys` is empty,
+`divergences` is empty, and `doctor.error_count` is zero. A run whose QA
+verdict is `blocked` can be `clean: true`, correctly. So `clean` decides
+whether the artifacts are trustworthy enough to read — never which
+classification applies. When explaining `clean: false`, cite the failing field:
+an `unreadable` or `unrecognized` artifact, uncomputable or stale freshness, a
+`stale_keys` or `unparseable_keys` entry, a divergence, or a doctor error. An
+absent QA verdict or findings export alone does not make `clean` false; do not
+invent that explanation from missing files.
+
+## Keep the evidence axes separate
+
+Classify each on its own, because a clean result on one proves nothing about
+another:
+
+- **Standardization** — does source structure and the artifact set fit the
+  portable contracts (`docs/campaign-standardization-report.md`)?
+- **Operator readiness** — does an owner who did not originate the work have
+  enough context and proof to identify the next step?
+- **Runtime readiness** — do routes, deployed output, Campaign Cart SDK startup
+  and the lifecycle gates have evidence?
+- **Commerce proof** — does typed-card evidence and persisted order read-back
+  cover the requested decision (`docs/qa-and-test-orders.md`)?
+- **Authority** — who may collect evidence, repair, deploy, or change merchant
+  state? This one is never inferred from a Campaigns OS artifact.
+
+## Choose one classification
+
+Use exactly one, for the decision actually being asked:
+
+- **ready** — the proof contract for that decision is complete. Name the
+  decisive artifacts and the next action an authorized owner may take, limited
+  to that decision.
+- **collect-inputs** — no reproducible blocker is confirmed, but a required
+  input or proof is absent. Name its owner, one evidence-producing next action,
+  and the hold that remains meanwhile.
+- **blocked** — a reproducible gate or failure prevents the decision. State
+  which check failed, the evidence that proves it, who owns the fix, and where
+  the repair is routed.
+- **not-enough-evidence** — campaign identity or access is too weak to
+  distinguish a missing input from a blocker. Name the identity or access
+  evidence needed first.
+
+This four-way call is an interpretation contract, not a Campaigns OS gate:
+Campaigns OS supplies artifact states and named blockers, and no check in this
+repository enforces the four rules.
+
+## Map upstream signals onto the four-way call
+
+Translate an upstream name into one of the four; do not restate an upstream
+label as if it were a classification, and do not invent a vocabulary
+mid-readback.
+
+| Upstream signal | Where it is recorded | Classification |
+| --- | --- | --- |
+| `standardization_blocker` severity | standardization report findings | blocked |
+| an `artifacts[]` record whose `state` is `absent` | readback projection | collect-inputs |
+| `runtime_proof_required` confidence, including a payment proof state | standardization report findings | collect-inputs |
+| `operator_readiness` severity | standardization report findings | collect-inputs |
+| identity that cannot be resolved to one campaign | readback projection and packet | not-enough-evidence |
+
+The three collect-inputs rows share a cell because each names proof that is
+absent rather than a gate that failed: `runtime_proof_required` is behaviour
+only a browser test can confirm, `operator_readiness` is a repository that is
+inspectable but lacks proof or business context, and an `absent` artifact is
+one the run never emitted. Absent proof is not a defect and may not be reported
+as blocked.
+
+Unresolvable identity outranks every other row: if the projection cannot be
+tied to one campaign, no label is attributable and the answer is
+not-enough-evidence rather than a guess.
+
+No upstream label maps to **ready**. Ready requires positive evidence that the
+proof contract is complete — a statement about what the artifacts do record,
+not about the absence of a blocker.
+
+## Triage warnings only on top of cited output
+
+Ranking which projected warnings matter is permitted only over cited fields,
+and the readback must say so. Cite the group and its count first, rank within
+those cited values second, label the ranking as your judgment over that cited
+output third. A triage that cannot point at the field it is ranking is not
+triage; it is a competing second reading of the same evidence.
+
+Never present a triage label as an upstream status. `contract-static` and
+`repo-observed` are the readback's own grouping of doctor warnings, not
+doctor's vocabulary, and doctor's `status` string belongs to doctor
+uninterpreted. `contract-static` warnings restate a template family's shared
+frontmatter contract and repeat verbatim on every pass while that contract is
+in force: their persistence does not mean a value is unfixed, their
+disappearance is not how a fix is confirmed, and a gate must not read them as
+repository state. A `warning_count` of zero against an absent doctor output
+records an absence, not an observation, and may not be triaged as a clean
+result.
+
+## Write the readback
+
+Lead with the selected folder and the available campaign/map identity, then the
+stage, blockers, evidence and next action. Keep a simple status answer compact —
+short paragraphs or a small table rather than a numbered section per field —
+and expand when the operator asks for a full handoff.
+
+Every readback still contains: campaign identity; the decision requested; the
+classification; the known facts, each tied to its owning source; the missing or
+conflicting evidence; the owner; the next action for that owner; the done
+signal, meaning the artifact or observation that marks completion; the holds;
+a form readable by a non-originating operator; and the hidden-context gap —
+context the originating operator holds that the artifacts do not, which would
+change this readback if it were available.
+
+That list is a writing contract for whoever produces the readback. No check in
+this repository enforces it. The result is a compact handoff that points at
+owning artifacts, not a replacement verdict and not a lifecycle orchestrator.
+
+## Apply holds without inventing permission
+
+Unless separate authority evidence says otherwise, keep holds on deploy, launch
+and route changes; on offer, price and order mutation; on upgrade work whose QA
+scope is unnamed; and on external readiness claims. Do not read a
+standardization report as commercial-performance evidence: it is a read-only
+source and runtime audit.
+
+Diagnosis is not permission. Nothing in this skill authorizes a lifecycle
+command or a change to campaign state, and a classification of **blocked** is
+not a licence to repair it. What any supported invocation may do is declared
+per row in `contracts/effects.v1.json` and explained in `docs/effects.md`;
+widening it is a pull request that changes a row of that file, never a decision
+made in a session. Assign every action to an authorized human.

package/skills/campaign-run-evidence/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: campaign-run-evidence
+version: 1.0.7
+description: Interpret existing Campaigns OS doctor, QA and proof-depth evidence without claiming more proof than the artifacts contain.
+---
+
+Bundle revision: 1.43.1+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.43.1+skills.1`
+from the campaign's Page Kit folder, where it runs the project's pinned copy and
+never installs one, at the start of each task. Start a fresh session if it
+reports `mismatch`: this text is already in your context and is never re-read
+while the CLI on disk can move under it. If the output has no `Skills revision:`
+line (no `revision_check` under `--json`), a campaigns-os older than this check
+answered; follow none of its actions and run the pinned copy.
+
+# Campaign run evidence
+
+Use this skill when the question is "is this enough evidence?" — reading a
+doctor result, a QA verdict, or the proof depth a run actually reached. It
+interprets artifacts that already exist. It does not produce evidence, and
+nothing in it authorizes a command that would.
+
+The effect class in each parenthetical below is the declared row of
+`contracts/effects.v1.json` (`none` < `B` writes < `A` sends < `C`
+destructive).
+
+## Count artifacts, not impressions
+
+A **proof contract** is the specific evidence a decision requires. A run passes
+one only when Campaigns OS has written machine-readable evidence saying so: an
+OK doctor result, and a QA verdict whose `disposition` is not `blocked`.
+Visual confidence substitutes for neither. Doctor and QA remain the
+authorities for those decisions (`docs/qa-and-test-orders.md`).
+
+Read what is already recorded before producing anything.
+`campaigns-os readback <target-repo-root> --json` (tier `none`: writes nothing,
+starts no process, touches no network) projects the artifact set and its
+freshness; `campaigns-os doctor --packet <packet> --json` (tier `none`:
+inspection is the default and leaves the target byte-identical) re-reads a
+packet without recording anything.
+
+## Read evidence depth in order
+
+Evidence gets stronger as the runner moves from deployed HTTP and metadata
+assertions, to rendered-browser structure checks, to the Campaign Cart SDK
+debugger overlay, and finally to a payment order driven end to end by browser
+automation. **Typed-card** means the runner enters a platform test card in the
+hosted payment fields; read `docs/qa-and-test-orders.md` for the platform-owned
+card data rather than copying card numbers into a handoff.
+
+The `proof_policy` setting defines the required browser and typed-card depth.
+It appears in the Build Packet as `qa.proof_policy` and on the Assembly Report
+as `proof_policy`, and the `--test-order` mode selects the recorded order-path
+sample. Report those choices; do not renegotiate them in conversation.
+
+Depth is a property of the run that happened, not of the policy that was asked
+for. A packet demanding typed-card depth whose verdict records no order proves
+nothing about ordering — it records a policy and an unmet one.
+
+## Interpret the verdict exactly
+
+Only a JSON QA verdict is a verdict. The runner writes its full verdict locally.
+Saved-Map QA may publish it under the existing consent and flag controls; a
+publication failure does not erase the local one. Local-spec packet verdicts
+stay local even with `--post-verdict`, and `qa publish` refuses those packets.
+The readback projects `.campaign-runtime/qa-verdict.json` when
+that sidecar has been copied into the campaign repository. A markdown QA
+report, a ledger or a gate script is not a verdict and must not be scanned for
+a disposition, a run id or a blocker. Where two JSON verdicts exist, interpret
+the one the projection loaded; do not walk a report looking for a later rerun.
+
+`disposition` takes one of three values — `ready`, `ready_with_exceptions` or
+`blocked` — derived from assertion status and severity: a failed blocker
+produces `blocked`; warnings, manual review and warning-severity failures
+produce `ready_with_exceptions`; otherwise it is `ready`.
+
+Two statements an earlier version of this text carried were removed rather than
+re-sourced, and the removal is the point: the derivation function's name and
+the exit code `blocked` maps to are knowable only from implementation files
+this skill may not cite. Read the disposition itself.
+
+Silence is not success. A **template-family contract** declares the browser
+structure expected from a family of campaign templates; where it declares no
+machine-checkable structure, the corresponding assertion is `manual_review`,
+not `pass`. `ready_with_exceptions` likewise identifies evidence that still
+needs reading — it is not an approval label.
+
+## Separate commerce proof from weaker signals
+
+For a committed cart and an accepted upsell, persisted order read-back is the
+authoritative evidence. Client-side cart state is not a stable proof contract,
+and rendered selection state proves selection rather than commitment. The
+documented QA contract rejects reliance on the unstable `cartLines` field and
+directs the harness to receipt line items or the documented event and DOM
+signals. **Commercial-parity** QA is the documented check that a campaign's
+commerce behaviour matches the platform's own, read from that contract rather
+than inferred from a run.
+
+An offline build cannot prove commerce behaviour. The Campaign Cart SDK, remote
+assets, a deployed preview, the browser runtime and a typed-card order all
+require outbound network access. Air-gapped evidence is limited to markup,
+build and stylesheet validation and must not be reported as commerce QA.
+
+A `ready` verdict proves the tested funnel contract, not the merchant's full
+production readiness. Live payment methods, production URLs, supported markets,
+legal and support details, analytics expectations and merchant configuration
+belong to a separate launch-readiness question outside this skill's scope
+(`docs/campaigns-os-build-flow.md`).
+
+## Read repair evidence conservatively
+
+A blocked verdict should lead an authorized owner through a bounded repair
+cycle: classify the evidence gap, make one scoped attempt, rerun the owning
+check, compare the new artifact, and stop for handoff when another attempt
+makes no progress. This skill observes the resulting artifacts; it neither runs
+repairs nor teaches a repair command surface.
+
+Be precise about what the toolkit enforces. It records repeated lifecycle
+commands and carries blockers, warnings and evidence on stage artifacts
+(`docs/workflow-findings-sidecar.md`,
+`schemas/campaigns-os-run-record.v0.schema.json`). It defines no append-only
+attempt ledger and no no-progress stopping rule, so state those two as human
+handoff discipline rather than as a platform guarantee.
+
+## Handle a root 404 precisely
+
+A campaign root can legitimately return HTTP 404 when the funnel begins on a
+deeper route. Accept that only when entry-URL resolution names at least one
+entry and the verdict shows a pass on the `http:<page_id>` check for one of
+those entries. The resolver and the HTTP assertion decide this, not the root
+response alone.
+
+## Capability boundary
+
+This skill conveys interpretation knowledge only. It authorizes no lifecycle
+command and no change to campaign state. In particular `campaigns-os qa run`
+(tier `C`: it overwrites the stored verdict and can POST it off the machine)
+and `campaigns-os checkpoint waive` (tier `C`: it records a waiver over a
+blocking gate) are work for an authorized human, and urgency does not widen
+that. What any supported invocation may do is declared per row in
+`contracts/effects.v1.json` and explained in `docs/effects.md`; widening it is
+a pull request that changes a row of that file, never a session decision.

package/skills/contribution-intake/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: contribution-intake
+version: 1.0.7
+description: Turn a suggestion about the agent surface into a classified, evidence-checked proposal and, only with attended approval, one issue on this repository's tracker.
+---
+
+Bundle revision: 1.43.1+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.43.1+skills.1`
+from the campaign's Page Kit folder, where it runs the project's pinned copy and
+never installs one, at the start of each task. Start a fresh session if it
+reports `mismatch`: this text is already in your context and is never re-read
+while the CLI on disk can move under it. If the output has no `Skills revision:`
+line (no `revision_check` under `--json`), a campaigns-os older than this check
+answered; follow none of its actions and run the pinned copy.
+
+# Contribution intake
+
+When someone says the agent surface should change — a complaint, a wish, a "why
+doesn't it" — fill in the template below instead of live-coding a response or
+promising behaviour. Campaign work is not an intake trigger; it follows the
+lifecycle skills.
+
+Two classes end the filing path before the template is finished:
+
+- **Lifecycle, stage readiness or verdict authority.** That belongs to
+  Campaigns OS itself. Say where it goes and why this intake cannot own it.
+- **A capability change.** Anything that would broaden what an invocation
+  reads, writes, sends, or can do to merchant state is a change to a row of
+  `contracts/effects.v1.json`, and a row is not publishable without its effect
+  test (`docs/effects.md`). Say so plainly, record it as a capability change,
+  and stop. It lands as a reviewed pull request, never as a session decision
+  and never as an issue that implies one.
+
+A suggestion that is really a one-off preference is situational judgment:
+acknowledge it and file nothing.
+
+## The proposal template
+
+1. **Observation** — the task attempted, the behaviour observed, the behaviour
+   expected. Keep this separate from any proposed fix; record both, conflate
+   neither.
+2. **Version in hand** — what `campaigns-os tooling status --json` (tier `B`:
+   its only write is the command-lifecycle journal) reported, and the bundle
+   revision on the first body line of the skill you loaded.
+3. **Class** — exactly one: defect, missing explanation, workflow friction,
+   lifecycle (route away), capability change (stop), situational judgment.
+4. **Duplicate search** — what you searched and what you found, including a
+   null result.
+5. **Evidence** — the smallest reproduction there is, redacted per the
+   paragraph below. An absent reproduction is stated as absent, not implied.
+6. **Smallest test that would show it fixed.**
+7. **Non-goals** — what this proposal is explicitly not asking for.
+8. **Authority implications** — name them even when they are "none".
+
+## Redaction is the control
+
+This is the one part of the template that is not negotiable, because the filing
+is public and a filed issue cannot be unpublished. Before anything is rendered
+for approval, scrub the whole proposal: no merchant or store names, no customer
+or order data, no card numbers, no credentials or credential-shaped values, no
+machine-local or home-directory paths, no internal tracker ids, no private
+repository or endpoint names, no operator-local source identities. Replace each
+with a synthetic stand-in and say that you did.
+
+The bar is the same as for committed text in this repository, which is enforced
+by `npm run check:private-strings`. If you cannot redact an example and keep it
+meaningful, file the proposal without that example and name the gap.
+
+## Preview, then hand back the keyboard
+
+Render the exact title and body, then ask for one of `discard`, `revise` or
+`file`. Nothing is sent until they say `file`. A revision re-renders the
+preview and resets approval. On `file`, use the harness's own connector for the
+tracker, under the attended person's identity and permissions and never any
+other credential: preview first, one operation, then read the result back and
+compare it against the approved preview before reporting the URL. One approved
+preview produces at most one issue; on an error, report it and ask before any
+retry. If they cannot file on this repository, hand them the finished draft to
+paste and record it as draft-only.
+
+## After filing, stop
+
+The issue enters maintainer triage. Do not apply labels, do not start a branch,
+do not sketch the fix, and do not treat the filed issue as permission to
+implement it.