Add new exercise for constraining responses

Introduced a new exercise under '02.product-restraint/02.problem.constrain-the-response' focusing on developing constrained responses to feature requests. This includes the addition of various configuration files, a CLI tool for local development, and a comprehensive README outlining the exercise objectives and requirements. Updated package-lock and tsconfig files to reflect new dependencies and paths, enhancing project organization to support this new exercise.

Author: kentcdodds

exercises/02.product-restraint/02.problem.constrain-the-response/.env

@@ -0,0 +1,2 @@
+# Optional (preview uses request origin by default)
+APP_BASE_URL=

exercises/02.product-restraint/02.problem.constrain-the-response/.env.example

@@ -0,0 +1,6 @@
+# Example environment variables for local dev, test, and preview deploys.
+# Copy this to `.env` for local development and local tests.
+
+# Optional (preview uses request origin by default)
+APP_BASE_URL=
+

exercises/02.product-restraint/02.problem.constrain-the-response/.oxlintrc.json

@@ -0,0 +1,7 @@
+{
+	"$schema": "./node_modules/oxlint/configuration_schema.json",
+	"extends": [
+		"./node_modules/@epic-web/config/oxlint-config.json",
+		"./tools/oxlint/oxlint-rules.json"
+	]
+}

exercises/02.product-restraint/02.problem.constrain-the-response/.prettierignore

@@ -0,0 +1,15 @@
+node_modules
+dist
+build
+.next
+.vercel
+.netlify
+coverage
+*.log
+.env*
+!.env.example
+package-lock.json
+yarn.lock
+pnpm-lock.yaml
+**/worker-configuration.d.ts
+public/client-entry.js

exercises/02.product-restraint/02.problem.constrain-the-response/AGENTS.md

@@ -0,0 +1,33 @@
+# epic-scheduler agent index
+
+Use Node.js v24+ and npm for installs/scripts (`npm install`, `npm run ...`).
+
+## Code style
+
+- Read and follow `docs/agents/code-style.md` before writing code.
+- Match the surrounding file style (quotes, semicolons, formatting).
+
+This file is intentionally brief. Detailed instructions live in focused docs:
+
+- Setup, checks, docs maintenance, preview deploys, and seeding:
+  - [docs/agents/setup.md](./docs/agents/setup.md)
+- Code style conventions:
+  - [docs/agents/code-style.md](./docs/agents/code-style.md)
+- Testing guidance:
+  - [docs/agents/testing-principles.md](./docs/agents/testing-principles.md)
+  - [docs/agents/end-to-end-testing.md](./docs/agents/end-to-end-testing.md)
+- Tooling and framework references:
+  - [docs/agents/harness-engineering.md](./docs/agents/harness-engineering.md)
+  - [docs/agents/oxlint-js-plugins.md](./docs/agents/oxlint-js-plugins.md)
+  - [docs/agents/remix/index.md](./docs/agents/remix/index.md)
+  - [docs/agents/cloudflare-agents-sdk.md](./docs/agents/cloudflare-agents-sdk.md)
+  - [docs/agents/mcp-apps-starter-guide.md](./docs/agents/mcp-apps-starter-guide.md)
+- Project setup references:
+  - [docs/getting-started.md](./docs/getting-started.md)
+  - [docs/environment-variables.md](./docs/environment-variables.md)
+  - [docs/setup-manifest.md](./docs/setup-manifest.md)
+- Architecture references:
+  - [docs/architecture/index.md](./docs/architecture/index.md)
+  - [docs/architecture/request-lifecycle.md](./docs/architecture/request-lifecycle.md)
+  - [docs/architecture/authentication.md](./docs/architecture/authentication.md)
+  - [docs/architecture/data-storage.md](./docs/architecture/data-storage.md)

exercises/02.product-restraint/02.problem.constrain-the-response/README.mdx

@@ -0,0 +1,37 @@
+# Constrain the Response
+
+👨‍💼 You qualified the request and established that a full account system is too
+big a response for what the product has actually proven so far.
+
+Now the job is to turn that judgment into a constrained response the team could
+actually align around without drifting back into feature momentum.
+
+🐨 Use your existing
+<InlineFile file="docs/planning/feature-framing-brief.md" /> to create a dedicated
+<InlineFile file="docs/planning/response-constraint-brief.md" /> artifact.
+
+This brief should answer: if the team does anything at all, what is the
+narrowest response worth considering right now?
+
+Your brief should cover:
+
+1. The narrow problem you are actually responding to
+2. The smallest response worth exploring first
+3. Which flows must stay unchanged to protect low friction
+4. What complexity you are explicitly refusing for now
+5. What cleanup, clarity work, or evidence should come before broader scope
+6. A clear recommendation for what the team should do next
+7. The success and failure boundaries for this constrained response
+
+Requirements:
+
+- Keep the response grounded in the product's current goals: finalized-plan
+  rate, low friction, and trustworthy repeat usage.
+- Protect the attendee response flow from account or sign-in pressure.
+- Avoid turning the create flow into a setup-heavy experience.
+- If you recommend a narrower first move, describe it as a product response,
+  not a full implementation plan.
+- Be explicit about what remains deferred, rejected, or still unsupported.
+
+💰 Strong product restraint is not just saying "no" to a big request. It is
+saying "yes, if at all, only at this level of scope and for this reason."