pattern-mcp 0.12.0 → 0.12.1

package/README.md

@@ -15,11 +15,13 @@ design reference.
 
 [Website](https://usepattern.sh) · [npm](https://www.npmjs.com/package/pattern-mcp) · [Report an issue](https://github.com/donaldrichard19-LVD/pattern-mcp/issues/new/choose)
 
-**Current release: v0.11.0** — adds `pattern-check-gate init`, a guided
-setup for the opt-in enforcement boundary (a `PreToolUse` hook plus a
-paired CI check) so a new component decision can be required, not just
-logged. See [Enforcement boundary: hook + CI
-gate](#enforcement-boundary-hook--ci-gate).
+**Current release: v0.12.0** — When you run `npx pattern-mcp` for the
+first time, Pattern now shows the optional enforcement boundary
+alongside the telemetry notice. This boundary includes a `PreToolUse`
+hook and a matching CI check. Together, they can require a decision for
+each new component instead of only recording it. See
+[Enforcement boundary: hook + CI gate](#enforcement-boundary-hook--ci-gate)
+for more details.
 
 <details>
 <summary><strong>Contents</strong> (click to expand)</summary>
@@ -1637,6 +1639,31 @@ Run non-interactively with `--yes` (accepts every safe default; branch
 protection is never auto-confirmed even then -- it's the one step that
 reaches outside your local filesystem into real, shared GitHub config).
 
+**You don't have to find this section to learn this exists.** Every
+`npx pattern-mcp` run surfaces it at the same first-run moment as the
+[telemetry notice](#telemetry):
+
+- **Always**, in every context, including when a real MCP client has
+  spawned this as a subprocess: a one-time, non-blocking stderr mention
+  that the enforcement boundary exists and the command above sets it up.
+  Same "prints once, gated by a marker file" discipline as the telemetry
+  notice -- tracked at `~/.pattern/enforcement_notice_shown`
+  (`PATTERN_ENFORCEMENT_NOTICE_PATH` to override), never repeats after
+  that regardless of whether you act on it.
+- **Only when stdin is a real terminal** (`process.stdin.isTTY`) --
+  meaning a human ran `npx pattern-mcp` bare in their own shell, never
+  true for a real MCP client's spawned subprocess -- it also offers a
+  genuine interactive prompt right there: *"Set it up now?"* A yes runs
+  the exact same `init` flow described above. The same JSON-RPC-channel
+  constraint that rules out an interactive telemetry prompt (see
+  [Telemetry](#telemetry)) applies here too, which is why this only ever
+  asks when nothing is piping protocol messages into stdin to begin
+  with.
+
+Set `PATTERN_NO_ENFORCEMENT_NOTICE` to suppress both halves. See
+`offerEnforcementSetupOnce` in `src/init-enforcement.ts` for the
+implementation.
+
 **Or set it up by hand**, two pieces, neither installed automatically:
 
 - **`.claude/settings.json`** wired to run `npx --yes
@@ -1773,7 +1800,9 @@ whether you act on it. There's no interactive y/n prompt: Pattern's stdin
 is the MCP JSON-RPC channel the client uses to talk to it, so blocking on
 stdin for a keypress would fight the protocol handshake instead of
 showing a dialog -- a stderr notice is the safe equivalent for a stdio
-MCP server.
+MCP server. The same first-run moment also surfaces the enforcement
+boundary, with the same constraint handled the same way -- see
+[Enforcement boundary: hook + CI gate](#enforcement-boundary-hook--ci-gate).
 
 **Why it exists.** Three things about real usage can't be answered from
 this repo alone: whether people actually come back and use Pattern on a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pattern-mcp",
-  "version": "0.12.0",
+  "version": "0.12.1",
   "description": "MCP server that turns your design guidance into a checkable process -- evaluates UI components from external libraries (shadcn/ui, 21st.dev, ReUI) or your own registered design system against a requirements checklist, then tells the agent whether to reuse an existing component or build one from a concrete design reference.",
   "type": "module",
   "main": "dist/index.js",