@mriekki/lean 0.4.3 → 0.4.5

package/assets/generated/core/core/process/DEPLOYMENT_ENABLEMENT.md

@@ -2,7 +2,7 @@
 
 Deployment enablement is the guided operational lane between delivered deployment engineering and `/deploy`.
 
-A repository may have multiple named deployment environments, such as Staging and Production. Each environment owns its own confirmed machine/target binding, readiness evidence, data/backup state, credentials, and deployment policy.
+A **logical environment is not a physical computer**. A repository may define `demo`, `staging`, `production`, or other named environments; one developer may use only a workstation, several environments may share one VPS, or a desired deployment may remain explicitly deferred.
 
 The normal human-facing entry point is state-driven:
 
@@ -10,120 +10,157 @@ The normal human-facing entry point is state-driven:
 /deployment-readiness <environment>
 ```
 
-The workflow discovers current state and continues from the furthest safe point. The human does not need to choose separate `discovery`, `enable`, or `resume` modes.
-
-For a read-only local overview use:
+Read-only overview:
 
 ```text
 /deployment-readiness status [environment]
 ```
 
-Omit the environment from `status` to summarize all configured named environments without automatically probing every remote machine.
+The workflow discovers current topology/state and continues from the furthest safe point. The human does not choose separate `discovery`, `enable`, or `resume` modes.
+
+## Topology before machine questions
+
+Resolve these independently when repository evidence provides them:
 
-Older invocations that include a deployment-enabler ID and/or `discovery`, `enable`, or `resume` may be normalized for compatibility, but they are not the normal interface.
+```text
+environment name / role / purpose
+placement
+isolation
+exposure
+binding state
+adapter
+target/provider binding
+failure domain
+```
 
-## Human-facing readiness model
+Current placement classes include:
 
-The workflow should ask about simple environment-machine facts before exposing deployment-tool internals.
+- `workstation` — local execution; current reusable container adapter is loopback-only;
+- `remote-target` — an explicitly bound remote machine/target;
+- `managed-service` — only when a provider-specific adapter actually exists;
+- `deferred` — desired deployment exists but no current target/provider binding is selected.
 
-Human-facing facts normally include:
+Do not ask remote-machine questions until `remote-target` is actually the selected placement.
 
-- environment name/role;
-- hostname or IP address;
-- SSH/deployment user when applicable;
-- non-default SSH port when applicable;
-- target OS when known.
+## Workstation readiness
 
-Internal Deployment Kit concepts such as logical target name / `targetName`, SSH alias, profile path, identity path, known-hosts path, address override, and trust-record storage should be discovered, reused, or derived whenever possible. They are not normal first questions.
+A one-machine local/demo topology is normal.
 
-If existing configuration is present, show the known simple facts and ask the human to confirm them before remote checks. Do not make the human reconstruct already-recorded values.
+For current `workstation-container` support, readiness focuses on:
 
-If setup is partial, show what is known and ask only for the smallest missing fact or authorization.
+- local Docker/runtime availability;
+- repository-distributed local deployment tooling;
+- exact immutable artifact/image identity;
+- local port/container ownership and health configuration;
+- persistence prerequisites where relevant;
+- Production policy if the logical environment is Production.
 
-If setup is absent, start with the selected machine's hostname or IP address, then ask one additional simple fact at a time only when required.
+It does not require SSH, a hostname, target profile, host trust, Caddy, Avahi, or a second computer.
 
-## Discover, confirm, verify, continue
+The adapter's current exposure is loopback. Do not silently widen it to LAN/public sharing.
 
-Normal readiness cadence is:
+## Remote-target readiness
+
+For remote placement, retain the strict target/access model:
 
 ```text
-select environment
-→ inspect existing local/repository setup
-→ show simple known facts
-→ human confirms or corrects them
-→ authorize read-only connectivity/identity verification
-→ run repository/Deployment-Kit doctor/verify checks
-→ reuse working access OR repair only missing setup OR onboard a new workstation
-→ verify target/platform/security/artifact/registry/data prerequisites
-→ ENVIRONMENT READY TO DEPLOY
-→ /deploy <environment>
+named environment
+→ explicit target binding
+→ current address/discovery
+→ independently verified host identity
 ```
 
-The next readiness invocation re-discovers current state and resumes automatically. It does not require a new mode word after discovery or repair.
+Human-facing facts normally include hostname/IP, deployment user, non-default port, and target OS when relevant.
 
-Remote probing does not occur merely to build the initial local summary.
+Internal target/profile/SSH/trust paths should be discovered, reused, or derived whenever possible rather than pushed onto the human as first questions.
 
-Address discovery is not host trust. When SSH is used, unknown or changed host identity stops access; readiness must not recover by disabling host-key verification, silently enrolling new trust, scanning/selecting another host, weakening network controls, or redirecting to another environment.
+If existing configuration is present, show known facts for confirmation. If partial, ask only for the smallest missing fact. If absent, start with the actual machine/address rather than an internal target identifier.
 
-## Readiness writes versus deployment writes
+Remote probing requires explicit read-only authorization. Address discovery never substitutes for cryptographic host identity. Unknown/changed SSH identity fails closed.
 
-Readiness may perform bounded prerequisite/setup writes when separately authorized and supported by repository tooling, such as:
+## Deferred readiness
 
-- local environment binding;
-- key/agent/trust setup;
-- target-side access setup;
-- runtime/platform prerequisite setup;
-- data/backup directory preparation;
-- firewall preparation;
-- registry credential setup.
+A deferred placement is intentional configuration state:
 
-Readiness does **not** hide application deployment inside environment preparation.
+```text
+DEPLOYMENT INTENTIONALLY DEFERRED
+```
 
-Application container/process deployment, release-specific migration, application route registration, live application health/readiness, live smoke validation, and release-specific deployment/rollback evidence belong to `/deploy` when the repository's deployment contract includes them.
+It must not block repository generation, local development, CI, documentation, or learning. Readiness should explain the next material decision—choose/configure a supported target/provider adapter—without guessing infrastructure or asking for secrets.
 
-This distinction prevents a first-deploy deadlock: readiness proves that the environment can safely accept the selected artifact; `/deploy` creates and validates the live application state.
+## Managed-service boundary
 
-## Pre-deploy versus post-deploy evidence
+Managed hosting is adapter-specific. General model knowledge may recommend a provider, but absent a live catalog/implementation contract it remains `CATALOG GAP`/planned.
 
-Pre-deploy readiness may require:
+No provider credentials or provisioning should occur merely because a deployment outcome is public/shareable.
 
-- verified machine/target binding and host identity;
-- actual target OS/architecture and supported runtime/platform;
-- validated/available route names and collision checks;
-- approved immutable artifact identity;
-- registry/artifact access readiness;
-- persistence/data/backup prerequisites;
-- migration capability;
-- deployment locking capability;
-- rollback/recovery capability and boundaries;
-- stronger Production backup/recovery prerequisites when applicable.
+## Colocated environments
 
-Do not require first-deploy evidence that can only exist after the selected artifact is deployed, such as live route resolution, live application health, smoke success, deployed release identity, or execution-backed rollback evidence for that release.
+Two logical environments may intentionally share one physical failure domain.
 
-`/deploy` establishes those post-deploy facts and reports them from repository/tool evidence.
+Keep their targetable scope, runtime/container, route, data, readiness evidence, and authorization independent. When Staging and Production share one target, surface:
 
-## Existing and new workstations
+```text
+TOPOLOGY NOTE
 
-On an already-configured workstation, successful strict verification means onboarding/setup questions are skipped.
+Staging and Production are logically isolated but share one physical
+failure domain. This may fit POC cost/learning goals, but it does not
+demonstrate host-level Production isolation.
+```
 
-On a partially configured workstation, diagnose the exact missing state and repair only that state after the applicable bounded authorization.
+Production backup/recovery/security/deploy/destructive gates remain stronger regardless of colocation.
 
-On a fresh workstation, guide the minimum required profile/key/agent/trust/binding setup using the approved repository/Deployment-Kit commands. Reuse an already-valid developer-to-machine relationship across POCs when policy/tooling permits; do not create duplicate credentials simply because a new POC uses the same box.
+## Readiness cadence
+
+```text
+select environment
+→ resolve topology
+→ inspect placement-relevant local state
+→ show/confirm known facts
+→ authorize relevant read-only verification
+→ repair only missing prerequisites under explicit write gates
+→ ENVIRONMENT READY TO DEPLOY
+→ /deploy <environment>
+```
+
+For workstation placement there is no remote-access stage. For deferred placement the workflow intentionally stops before verification/provisioning.
+
+## Readiness writes versus deployment writes
+
+Readiness may perform bounded setup writes when separately authorized and supported by installed tooling, such as local configuration, SSH key/agent/trust setup, target-side access setup, runtime/platform preparation, data/backup directories, firewall preparation, or registry/provider credential configuration.
+
+Readiness does **not** hide application deployment inside setup.
+
+Application runtime deployment, release-specific migration, route/port publication, live health/readiness, smoke validation, and release-specific evidence belong to `/deploy` when the installed adapter defines them.
+
+## Pre-deploy versus post-deploy evidence
+
+Readiness proves only facts that can exist before deployment, such as:
+
+- logical environment/topology selection;
+- supported adapter availability;
+- local Docker readiness or verified remote target/identity depending on placement;
+- target OS/runtime when applicable;
+- artifact identity/access;
+- route/port ownership availability;
+- persistence/backup/migration prerequisites;
+- deployment lock/recovery capability;
+- stronger Production prerequisites.
+
+First-deploy live route, health, smoke, deployed-release identity, and release-specific rollback evidence are post-deploy facts owned by `/deploy`.
 
 ## Environment independence
 
-Readiness is environment-specific. Readiness of Staging does not prove Production is ready, and failure of one environment must never cause fallback to another environment or machine.
+Readiness of one logical environment never proves another environment ready—even if both share one physical target.
+
+Failure of one environment never redirects to another environment, machine, provider, or wider exposure.
 
-Production remains a role with stronger deployment, artifact, backup, recovery, and Human-in-the-Loop policy where required. It does not use a separate readiness command.
+Production remains a logical role/policy with stronger gates, not a separate readiness command or a requirement for a dedicated physical computer.
 
-Once the selected environment is ready to deploy, the repeatable deployment entry point is:
+Once ready:
 
 ```text
 /deploy <environment>
 ```
 
-`/deploy` verifies the selected environment/target/artifact evidence, presents the applicable write gate immediately before execution, delegates deterministic deployment mechanics, and then verifies repository-defined live route/readiness/smoke/deployment evidence.
-
-A Production deployment remains separately authorized and never becomes implicit because readiness passed. A non-production remote deployment still requires the repository/tool's bounded remote-write authorization.
-
-Remote read-only authorization never implies permission for writes. Secret values stay out of tracked documentation and logs. Database restore/destructive recovery remains a separate decision when data safety warrants it.
+`/deploy` verifies current topology/target/artifact evidence, presents the exact installed-tool authorization gate, delegates deterministic mechanics, and verifies placement-relevant live evidence.

package/assets/generated/core/core/process/LEAN_ENGINEERING_GUIDE.md

@@ -0,0 +1,317 @@
+# Lean POC Platform — Engineering Guide
+
+> This Markdown guide began as a repository-friendly conversion of the **Lean POC Platform | Integrated Briefing** prepared 16 October 2026. The platform has continued to evolve. Live repository evidence, accepted baselines, and current process docs outrank historical example/status statements when they differ.
+
+## From Idea to Engineering Environment
+
+**Core promise:** provide an easy way to turn a personal software idea into a reproducible, AI-enabled engineering project — with technology choice, streamlined setup, deliberate learning, real SDLC practices, and a deployment model that can scale from one-machine local use to distinct Staging / Production environments when the project actually needs them.
+
+```mermaid
+flowchart LR
+  IDEA[Idea] --> DISCOVERY[Discovery]
+  DISCOVERY --> GENERATE[Generate]
+  GENERATE --> BUILD[Build + Learn]
+  BUILD --> DELIVER[Deliver]
+  DELIVER --> DEPLOY[Deploy when selected]
+```
+
+Technology choice + deterministic setup + Lean AI workflow + learning + CI + explicit deployment topology.
+
+---
+
+## 1. Purpose & Executive Thesis
+
+### Make experimentation easy without making engineering disposable
+
+The platform lowers the friction of starting a personal project while preserving enough professional engineering structure that the work is repeatable, teachable, and credible.
+
+| Principle | Meaning |
+| --- | --- |
+| Low friction | Start from a short idea instead of hand-assembling repository conventions, setup scripts, AI instructions, and workflow boilerplate. |
+| Choice | Select a technology direction based on project needs or learning goals, with explicit support-state signals rather than hidden assumptions. |
+| Discipline | Use a Lean Agentic workflow with bounded implementation, review, CI evidence, and meaningful human acceptance points. |
+| Learning | Build understanding alongside code through work-item guides, code walkthroughs, learning review, and targeted coaching. |
+| Realism | Exercise containerization, source control, CI, releases, environment isolation, and deployment tradeoffs without pretending every POC needs dedicated Staging/Production computers. |
+| Repeatability | Create self-contained generated repositories with explicit provenance and controlled platform updates. |
+
+### Why this is different from “generate me an app”
+
+The outcome is not just source code. It is a project with an engineering operating model: approved scope, stack decision, workspace conventions, AI behavior, work items, setup/readiness, CI, delivery gates, learning support, and deployment boundaries.
+
+---
+
+## 2. Value Stream
+
+### One guided path from idea to a working engineering system
+
+AI is used where conversation and judgment help; deterministic tooling is used where reproducibility and safety matter.
+
+1. **Define** — conversational discovery turns a vague idea into users, workflows, state/lifecycle, success criteria, non-goals, security/privacy, and learning goals.
+2. **Choose** — technology and deployment outcome/topology are selected against a live catalog and recipe model, with support maturity made visible.
+3. **Generate** — a human-approved manifest drives deterministic generation of a self-contained repository and AI-ready workspace.
+4. **Build** — work items flow through Lean implementation, tests, review, meaningful-diff acceptance, and CI-backed delivery.
+5. **Learn** — the same work becomes deliberate practice through walkthrough, learning review, and focused coaching.
+6. **Operate** — when deployment is selected, the logical environment topology is explicit: workstation, remote target, supported provider adapter, or intentionally deferred.
+
+**Design rule:** conversational product discovery is separate from deterministic repository generation.
+
+---
+
+## 3. Platform Architecture
+
+### Reusable platform layers; self-contained consumer projects
+
+Clear ownership boundaries keep process, package transport, orchestration, deployment mechanics, and product state from collapsing into one AI-controlled blob.
+
+```mermaid
+flowchart TB
+  BOOT[POC Bootstrap<br/>Discovery, catalog, manifests,<br/>deterministic generation] --> POC[Generated POC<br/>self-contained consumer]
+  CORE[Agentic Core<br/>Workflow, agents, skills,<br/>HITL gates, learning] --> POC
+  PLATFORM[Lean Platform / @mriekki/lean<br/>Exact accepted reusable components] --> POC
+  CONTROL[Control Plane<br/>GitHub App orchestration<br/>and safe publication] --> POC
+  DEPLOY[Deployment Kit<br/>Workstation + remote-target mechanics] --> POC
+```
+
+| Layer | Responsibility |
+| --- | --- |
+| POC Bootstrap | Discovery protocol, catalog/support states, approved `POC_BOOTSTRAP.json`, deployment topology intent, deterministic generation, setup/readiness helpers, work-item materialization. |
+| Agentic Core | Reusable workflow behavior, agents/skills, Human-in-the-Loop gates, review/delivery semantics, learning flows, topology-aware deployment orchestration. |
+| Lean Platform | Consumer-facing `@mriekki/lean` package that assembles exact accepted reusable components and records provenance. |
+| Control Plane | GitHub App orchestration for target validation, short-lived scoped credentials, deterministic generation, and safe publication. |
+| Deployment Kit | Reusable one-workstation loopback-container runtime plus strict remote target/access, Ubuntu/Docker/Caddy routing, persistence, and scoped tear-down mechanics. Managed hosting remains adapter-specific rather than generic implied support. |
+| Generated POC | Owns product scope, architecture, code/tests, work items, CI evidence, logical environment/topology facts, concrete deployment bindings, accepted baselines, and implementation history. |
+
+**Architectural outcome:** a generated POC remains usable on its own. Normal development and deployment do not depend on sibling clones of the platform repositories.
+
+---
+
+## 4. Technology Choice
+
+### Standardization without stack lock-in
+
+The platform separates “what I want to use” from “what the bootstrap system can automate confidently today.”
+
+- **Choice remains explicit.** Stack selection is part of discovery and can reflect product constraints, developer preference, or a learning objective.
+- **Support is declared.** Catalog entries and recipes expose support state.
+- **Gaps are visible.** An uncataloged recommendation can still be reasonable engineering advice, but it is labeled `CATALOG GAP` rather than presented as supported automation.
+- **Automation can grow.** New recipes, deployment adapters, and support states can be added to repository-owned catalog definitions without changing the overall experience.
+
+Reference recipes captured in the original source briefing:
+
+- `dotnet-react-sqlite` — Partial support
+- `java-angular-postgres` — Partial support
+- `java-angular-sqlite` — Partial support
+- `react-vite` — Partial support
+
+**Implication:** avoid both a rigid golden path that blocks experimentation and ungoverned AI that implies unsupported stacks/providers are production-ready. Choice is broad; automation claims stay evidence-based.
+
+---
+
+## 5. Bootstrap & Provenance
+
+### Definition is conversational; generation is deterministic
+
+Once scope is approved, generation authority becomes an explicit manifest rather than conversation memory.
+
+```mermaid
+flowchart LR
+  IDEA[Idea] --> DISC[Discovery]
+  DISC --> SCOPE[Scope + non-goals]
+  SCOPE --> STACK[Stack + support]
+  STACK --> ITEMS[Work items]
+  ITEMS --> MANIFEST[Approved manifest]
+  MANIFEST --> GEN[Generate + publish]
+  GEN --> CI[CI]
+  CI --> SETUP[Clone + setup]
+  SETUP --> ACCEPT[Doctor + acceptance]
+  ACCEPT --> START[/start-work]
+  START --> IMPL[Implement + review]
+  IMPL --> DELIVER[/deliver]
+  DELIVER --> MERGE[Merge gate]
+```
+
+1. Human approves schema-v2 `POC_BOOTSTRAP.json` with initial work items and an exact `@mriekki/lean` package version/profile/integrity.
+2. The private target repository is seeded with only the approved manifest; a public Control Plane request identifies only the repository.
+3. The Control Plane validates the private seed, uses short-lived scoped credentials, obtains the exact package artifact, and verifies integrity before reusable target mutation.
+4. Bootstrap materializes project-owned content; the exact Lean package applies its reusable profile only after drift/collision preflight.
+5. The generated repository records umbrella and component-native baselines, is published without force/history rewrite, and must pass default-branch CI before local setup continues.
+
+### Why provenance matters
+
+A future AI session can inspect what was actually accepted instead of guessing which reusable behavior or generator version produced the workspace.
+
+---
+
+## 6. Generated Developer Experience
+
+### Generation creates an engineering workspace — not just folders
+
+A project can be generated, set up, and accepted as an engineering workspace even when its application scaffold or deployment binding is intentionally deferred.
+
+| Area | Generated experience |
+| --- | --- |
+| Workspace shell | VS Code workspace, editor conventions, `.gitignore`/`.gitattributes`, settings/extensions, and pre-scaffold launch surfaces. |
+| Agent behavior | `AGENTS.md` plus repository-local agents, skills, scoped instructions, process guidance, and provider-specific integration. |
+| Project definition | Materialized product scope, roadmap, approved work items, architecture/design context, deployment topology, and implementation/learning guidance. |
+| Setup + doctor | Workstation setup and readiness checks stay distinct from human editor/workspace acceptance. A deferred deployment target is not a failed development workspace. |
+| CI baseline | CI exists before substantive implementation and becomes reusable evidence throughout delivery. |
+| Provenance | `POC_BOOTSTRAP.json`, `LEAN_BASELINE.json`, component baselines, `DEV_ENVIRONMENT.json`, and `SCAFFOLD_PLAN.json` make generated state inspectable. |
+
+**Important distinction:** machine success is evidence, not human acceptance. Setup and doctor checks can prove tools are ready; the human still decides whether the checkout is actually usable.
+
+---
+
+## 7. Lean Agentic Engineering
+
+### AI handles mechanics; humans retain engineering authority
+
+The Lean workflow removes ceremonial prompts while preserving explicit control where scope, acceptance, merge, deployment, or destructive actions are consequential.
+
+```mermaid
+flowchart LR
+  WORK[Work Item<br/>requirements + plan] --> IMPLEMENT[Implement<br/>AI-assisted bounded change]
+  IMPLEMENT --> REVIEW[Review<br/>Reviewer + meaningful diff]
+  REVIEW --> DELIVER[Deliver<br/>commit + push + PR + CI]
+  DELIVER --> LEARN[Learn<br/>walkthrough + review + coach]
+  LEARN --> WORK
+```
+
+- **`/start-work <ID>`** loads approved work-item context, refines requirements/plan when warranted, then authorizes bounded implementation and routine branch setup.
+- **Implement + Review** is AI-assisted bounded change with tests and Reviewer evidence, followed by human meaningful-diff acceptance.
+- **`/deliver`** performs selective stage, staged-diff verification, commit, push, PR creation/update, and CI inspection after delivery is invoked.
+- **Merge gate** remains one explicit “Merge and finalize delivery?” decision. If evidence materially changes, review re-opens.
+- **Post-merge** verifies default-branch CI and safely cleans up only the delivered short-lived branch.
+- **`/wait-what`** is read-only communication repair: explain what just happened without silently doing work or authorizing the pending action.
+
+**Governance pattern:** standardize high-frequency routine mechanics; preserve human authority for material requirements, meaningful implementation acceptance, merge/finalization, release publication, Production deployment, and destructive operations.
+
+---
+
+## 8. Learning Mechanism
+
+### Use AI to increase capability, not only throughput
+
+The system treats a personal POC as both a software deliverable and a deliberate learning vehicle — without turning learning into a release gate.
+
+- **Embedded context** — work-item Implementation & Learning Guides connect engineering outcomes to concepts, reasoning prompts, things to notice, hands-on opportunities, and learning evidence.
+- **Code walkthrough** — `/code-walkthrough` explains the actual implementation, architecture boundaries, control flow, and important tradeoffs after the work exists.
+- **Learning review** — `/learning-review` distinguishes what the developer can explain from what was merely generated and accepted.
+- **Targeted coaching** — `/coach` focuses on specific gaps instead of re-teaching the whole project.
+- **Evidence labs** — `/db-lab` and `/system-lab` reconstruct current database/system evidence and support change-focused learning without requiring hand-maintained diagrams.
+
+### Comprehension model
+
+Distinguish:
+
+- personally implemented/used;
+- AI-generated but reviewed/understood;
+- studied/practiced;
+- not yet understood.
+
+The goal is evidence of understanding, not artificial claims of authorship.
+
+### No delivery tax
+
+Learning is optional and deliberately non-blocking. The project can be delivered once engineering acceptance is satisfied, even if the developer chooses to defer the learning flow.
+
+---
+
+## 9. Environments & Deployment
+
+### Logical environments, flexible physical topology
+
+Environment purpose is independent from machine count.
+
+```mermaid
+flowchart TB
+  DEV[Development] --> CHOICE{Desired deployment outcome}
+  CHOICE --> LOCAL[Demo on workstation<br/>container + loopback]
+  CHOICE --> REMOTE[Remote target<br/>one or more logical environments]
+  CHOICE --> DEFER[Deferred binding<br/>continue development now]
+  CHOICE --> PROVIDER[Managed provider<br/>only through supported adapter]
+```
+
+Keep these dimensions separate:
+
+```text
+purpose / role
+placement
+isolation
+exposure
+binding state / adapter
+target or provider
+failure domain
+```
+
+Examples:
+
+| Topology | Meaning |
+| --- | --- |
+| One workstation | `demo` may run as a loopback-only container; no second PC or SSH onboarding required. |
+| Separate remote hosts | Staging and Production can each have their own target/failure domain. |
+| One shared VPS | Staging and Production can remain separate logical environments while sharing a physical failure domain; Lean must state that this does not prove host-level Production isolation. |
+| Deployment deferred | A desired shareable/production-like outcome can be recorded without forcing immediate infrastructure provisioning. |
+| Managed provider | Only an implemented/cataloged provider adapter may be called supported; otherwise it is `CATALOG GAP`/planned. |
+
+Production remains separately authorized regardless of physical placement. Colocation never turns Staging validation into Production evidence and never weakens Production data/deployment gates.
+
+### Current maturity statement
+
+Reusable deployment mechanics exist for a loopback-only workstation-container path and the strict remote Ubuntu/SSH path. Bootstrap support remains partial until the corresponding package-delivered unrelated generated-consumer proofs are completed. Managed service hosting is an adapter boundary rather than a generic support claim.
+
+---
+
+## 10. Concrete Historical Example
+
+### Family Meal Planner v3: a generated consumer, not a platform fork
+
+The original briefing used Family Meal Planner v3 to demonstrate re-baselining a mature product definition into the reusable platform without copying historical execution state.
+
+- **Product goal:** private, mobile-friendly household Recipe Library with structured recipes, ingredients/tags, lifecycle management, search/filtering, and family ratings.
+- **Selected stack:** `dotnet-react-sqlite` recipe with partial support; generic scaffold intentionally deferred rather than allowed to overwrite mature architecture decisions.
+- **First work item:** EN-001 — Application Foundation / Walking Skeleton: prove React, ASP.NET, browser-to-API, SQLite through approved layers, dependency injection, health/system info, Compose, and CI.
+- **App-specific deployment model in that reference consumer:** Production and Staging are distinct Ubuntu environments over trusted-LAN SSH with separate target/access contracts and no cross-environment fallback.
+- **Learning goal:** use the project as a hands-on software-engineering POC and build enough understanding to review and explain the system rather than only accept generated implementation.
+- **Lifecycle point in the original briefing:** the v3 repository had an approved seed manifest and was at the GitHub-first generation handoff when the original briefings were prepared.
+
+The FMP topology is an **example consumer choice**, not a reusable requirement for other Lean users.
+
+**Why the example matters:** it demonstrates that the platform can preserve non-trivial product, architecture, work-item, deployment, and learning intent while still applying a standardized engineering workspace and Lean operating model.
+
+---
+
+## 11. Boundaries, Maturity & Takeaway
+
+### Make the easy path a disciplined path
+
+The strongest claim is not that AI can do everything. It is that a reusable operating model can make disciplined engineering the lowest-friction way to explore an idea.
+
+- **Not “any stack, fully automated.”** Technology choice is broad; Bootstrap automation is claimed only where the live catalog supports it.
+- **Not “every POC needs servers.”** One-machine local/demo and explicitly deferred deployment are valid outcomes.
+- **Not generic cloud support.** A plausible provider is not supported until a provider adapter is cataloged, implemented, and proven.
+- **Not autonomous Production.** Merge, CI, or release publication never implies Production deployment. Production and destructive operations remain separately gated regardless of placement.
+- **Not model-dependent.** Repository-local workflow assets define behavior; Core does not rely on one fixed AI model to preserve the engineering process.
+- **Not hidden regeneration.** Generated POCs are self-contained consumers. Reusable updates go through controlled package/baseline paths rather than silent wholesale regeneration.
+- **AI drift is bounded.** Repository protocol, catalog, baselines, and project-owned artifacts outrank conversational inference about project state.
+- **Still a POC platform.** This is a disciplined engineering POC platform with strong foundations and explicit remaining proof/maturity work — not a finished enterprise developer platform.
+
+### Strategic takeaway
+
+This is a small-system proving ground for AI-native engineering: low-friction project creation, governed technology choice, repository-owned AI behavior, realistic delivery/deployment practice, and learning built into the same workflow.
+
+---
+
+## Source Basis
+
+The original integrated briefing retained source basis from:
+
+- `lean-poc-bootstrap`
+- `lean-agentic-core`
+- `lean-platform`
+- `lean-poc-control-plane`
+- `lean-poc-deployment-kit`
+- `family-meal-planner-v3`
+- `Lean_Coding_Projects_Shared_Handoff_v3_1.md`
+- `Mark_Coding_Projects_Handoff_v3_1.md`
+
+Historical example/status statements originated in the briefing prepared 16 October 2026. Current reusable claims in this guide are constrained by live repository evidence.