Customer context

Where the brand facts come from, and the one folder an agent may never write.

What the baseline guarantees

`<demo>\customer-context\` is a read-only folder in the demo root; it does not exist yet on this solution; create it
and put the customer material in it before branding starts.
It holds what the customer or sales prep handed over verbatim: intro-call notes and transcript
exports, project-alignment decks, sample customer-of-customer files (per-account product
portfolios, pricing extracts), email-thread exports (.msg / .eml), and any other supplied
artefact. Exact filenames are project-specific.
Reading it is expected — that is the point. Reading it through a byte-stream tool is still
reading; the rule is about writes only.
Writing to ANY path containing `customer-context` (case-insensitive, both separators) is a
HARD ABORT. There is no approve-and-log branch, because a customer-context write is never
necessary. Transformed output goes to `<demo>\notes\` (your own working notes) or
`<demo>\extracts\` (data derived FROM customer-context).
The canonical abort message, not to be paraphrased:
  "ABORT -- this would write to a read-only customer-context folder. The `customer-context\`
   directory holds intro-call materials, call summaries, and customer-supplied artefacts that
   must not be modified by demo-build automation. Did you mean `<demo>\notes\` (your own
   working notes) or `<demo>\extracts\` (transformed/derived data extracted FROM
   customer-context)?"
The rule deliberately over-matches: `notes/customer-context-summary.md` aborts too. That is
intentional friction. `<demo>\customer-contextx\foo.md` does NOT match (no separator).
Why it exists: if any of those files shows as modified in `git status` after a demo build, the
customer's read is "they got our material and modified it without asking" — a bigger signal
than any technical bug.
Sister contract, same mental model, three branches instead of one: the customisations ledger at
`<demo>\CUSTOMISATIONS.md`. A write to `Dynamicweb.Host.Suite/Controllers/**/*.cs`,
`Providers/**`, or any `*Controller.cs` prompts Approve+log / Refactor instead / Cancel. What
does NOT count as a customisation and ships unprompted: NotificationSubscriber subclasses,
static helpers, custom item-type XMLs, Razor template edits (.cshtml is explicitly outside the
glob), custom fields on AccessUser / EcomProducts / ProductGroup, read-only SQL helpers.
Projects routinely over-read the rule and bar notification subscribers, which then forces SQL
backfills that should have been runtime subscribers.
Never put a password, API key or bearer token in CUSTOMISATIONS.md — it is git-tracked.
Passwords live in the gitignored notes/credentials.local.md and are referenced by pointer.
A plaintext password in the tracked ledger is an audit finding.

Which skill covers it

dw-demo-base (dynamo: false) — references/customer-context.md is the canonical contract
(rationale §1, contents §2, abort message §3, path matching §4, three-place communication §5,
the CLAUDE.md drop §6, the bypass detector §7); references/customisations.md is the sister
ledger contract (what the rule forbids vs not, the row format, the end-of-phase audit).
references/demo-tactics.md turns the read into `<demo>\notes\wording.md`.

Which MCP tools brand it

None. This is a filesystem contract on the demo solution folder, not on the DW instance.
No MCP tool reaches it and none should.

Verify

Shell, from the solution root, at the end of every phase:
    git status --porcelain "customer-context/"
Zero output = the contract held. Any output = a bypass; investigate before declaring the phase
complete.
Ledger audit, same cadence: file count under Dynamicweb.Host.Suite/Controllers/ equals the
CUSTOMISATIONS.md row count. controllerCount > ledgerCount means a preflight was bypassed.