@mriekki/project-forge 0.0.0-stage → 2.0.0

package/assets/generated/core/core/skills/system-lab/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: system-lab
+description: "Optional evidence-backed advanced system-design lab for architecture, runtime flows, APIs, failures, capacity, performance, observability, security, messaging, deployment, testing, evolution, debugging, and interview practice."
+argument-hint: "[architecture|runtime|api|failure|capacity|performance|observability|security|messaging|deployment|testing|debug|changes|evolve|compare|interview|topic] [work-item]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# System Lab
+
+`/system-lab` is an optional advanced learning surface built from current repository/runtime evidence. It complements `/coach`; it does not replace the engineering workflow or authorize implementation changes.
+
+For detailed usage, model semantics, and examples, read `docs/process/SYSTEM_DESIGN_LEARNING_WORKBENCH.md` in a greenfield consumer (or canonical `core/process/SYSTEM_DESIGN_LEARNING_WORKBENCH.md`).
+
+## 1. Core contract
+
+- Start from the current repository and the minimum safe evidence needed for the requested lens.
+- Treat the repository/runtime/configuration evidence as authoritative; generated diagrams are disposable projections, never a second source of truth.
+- Re-discover evidence whenever the lab is invoked. Do not make the human remember to refresh or rebuild a diagram.
+- Prefer the distributed `tools/project-forge-system-lab/system-workbench.py` when present. It always rebuilds its model from current evidence and may compare with its prior disposable snapshot.
+- Never inspect Production credentials, Production data, or secret values.
+- Do not change production code, configuration, infrastructure, schemas, data, or deployment state while in System Lab mode.
+- Do not claim runtime behavior from static topology alone. Label evidence precisely.
+- Discovered implementation defects return to the normal engineering workflow; do not silently fix them here.
+- Learning is optional and never blocks delivery.
+
+## 2. Evidence labels
+
+Use these labels consistently:
+
+```text
+CONFIRMED BY CODE       — directly observed in source/configuration/tests
+CONFIRMED BY RUNTIME    — directly observed in safe runtime/telemetry evidence
+DOCUMENTED INTENT       — stated in project documentation/ADR/requirements
+INFERRED                — reasonable interpretation from incomplete evidence
+UNKNOWN                 — evidence is insufficient
+LEARNER ASSUMPTION      — value supplied for a design/capacity exercise
+```
+
+A diagram edge is not automatically proof that a runtime call occurred. A dependency discovered from configuration/package references may still be only structural evidence.
+
+## 3. System-design competencies
+
+Assess independently rather than using one generic "system design level":
+
+```text
+requirements + scope framing
+capacity estimation + workload modeling
+API + contract design
+service/module decomposition
+data/storage selection
+caching
+messaging + asynchronous workflows
+consistency + distributed coordination
+scaling + partitioning
+availability + fault tolerance
+latency + performance
+runtime/deployment topology
+observability + SLO reasoning
+security + abuse resistance
+cost/complexity awareness
+architecture evolution
+incident/debug reasoning
+testing/verification strategy
+tradeoff defense
+interview communication
+```
+
+Use the common L1-L6 levels, but record evidence per competency.
+
+## 4. Architecture lenses
+
+Treat one system model as the basis for multiple views:
+
+```text
+STRUCTURE      components and dependencies
+RUNTIME        request/event path for a scenario
+API            contracts, boundaries, callers, downstreams
+DATA           stateful components and data movement
+SCALE          load assumptions and bottleneck questions
+FAILURE        failure domains and propagation hypotheses
+CONSISTENCY    places state may disagree or ordering/idempotency matters
+PERFORMANCE    latency budgets, fan-out, saturation, timeout/retry behavior
+OBSERVABILITY  metrics/logs/traces/SLO evidence and gaps
+SECURITY       trust boundaries, authn/authz, secrets/PII exposure, abuse controls
+MESSAGING      producers/consumers, delivery semantics, ordering, retries, DLQ
+DEPLOYMENT     processes/containers/nodes/environments and rollout concerns
+TESTING        verification boundaries and untested risk
+CHANGES        architecture impact of the current/recent work item
+EVOLUTION      what complexity becomes justified as constraints change
+```
+
+If evidence for a lens is absent, show the gap instead of inventing detail.
+
+## 5. Interactive workbench
+
+When `tools/project-forge-system-lab/system-workbench.py` exists, prefer it for a current project snapshot.
+
+The tool is read-only and dependency-free. It:
+
+- scans current repository evidence for application/service/frontend/library/datastore/cache/messaging/external/deployment/test signals;
+- records provenance for inferred components and dependencies;
+- generates a stable evidence fingerprint and current Git commit when available;
+- automatically compares with the prior disposable snapshot in the selected output directory;
+- accepts optional explicit model JSON for richer known architecture, scenarios, failure behavior, decisions, SLOs, and metadata;
+- accepts changed-file paths so a delivered work item can be overlaid on the architecture;
+- creates self-contained `index.html` plus `workbench.json`;
+- supports draggable nodes, search, zoom, clickable nodes/edges, scenario highlighting, lens switching, change overlays, failure exploration, capacity calculations, latency budgets, scale/evolution prompts, design drills, and interview perturbations.
+
+Generate into a stable per-repository temp/cache directory so the prior disposable snapshot can be used for change comparison. Do not commit generated output unless explicitly requested.
+
+## 6. Scenario-to-architecture tracing
+
+For a scenario such as checkout, authentication, background processing, or notification:
+
+```text
+entry point
+→ participating components
+→ synchronous calls
+→ state reads/writes
+→ asynchronous messages
+→ external dependencies
+→ user-visible/result state
+```
+
+Highlight only evidence-backed participants. If the sequence is inferred from topology rather than captured runtime evidence, say so.
+
+Ask the learner to explain the path before filling gaps when that improves learning.
+
+## 7. Prediction before reveal
+
+For advanced learning, default to making the human predict before revealing the explanation when practical.
+
+Examples:
+
+```text
+What fails if this dependency times out?
+Which component becomes the bottleneck at 10x traffic?
+Where can duplicate delivery cause damage?
+Which signal would distinguish database latency from downstream latency?
+What consistency guarantee does the requirement actually need?
+```
+
+Do not turn every interaction into a quiz. Explanation-first remains valid when explicitly requested.
+
+## 8. Failure and debugging mode
+
+Failure mode should distinguish verified behavior from topological hypotheses.
+
+```text
+symptom/failure injection
+→ learner predicts impact
+→ identify failure boundary
+→ likely propagation
+→ distinguishing telemetry/evidence
+→ resilience behavior
+→ user-visible effect
+→ prevention/design alternatives
+```
+
+Useful perturbations include database/cache/queue/dependency unavailability, slow dependency, duplicate/delayed/out-of-order messages, retry amplification, queue backlog, regional failure, network partition, bad deployment, and traffic spikes.
+
+For `/system-lab debug`, reveal evidence incrementally and ask what evidence the learner would inspect next. Do not implement the fix in learning mode.
+
+## 9. Capacity and performance mode
+
+Use explicit learner/design assumptions, not invented production numbers.
+
+Connect:
+
+```text
+DAU / active users
+requests per user
+peak multiplier
+read/write mix
+payload size
+retention
+fan-out
+latency/SLO target
+```
+
+with derived average/peak RPS, write RPS, bandwidth, storage growth, and latency-budget reasoning. Explain simplifying assumptions.
+
+A scale slider or changed workload is a prompt to re-evaluate bottlenecks and complexity; it is not proof that a specific technology is required.
+
+## 10. Distributed-systems and messaging mode
+
+Practice:
+
+- strong/eventual/read-after-write consistency;
+- optimistic concurrency and conflict handling;
+- idempotency and deduplication;
+- at-least-once delivery and the limits of "exactly once" claims;
+- ordering and partitioning;
+- retry/backoff/DLQ behavior;
+- outbox/inbox patterns;
+- sagas/compensation;
+- distributed locks only when justified.
+
+Use timelines when helpful. Make the learner reason about state before and after duplicate, delayed, failed, or reordered events.
+
+## 11. API, security, observability, testing, and deployment lenses
+
+API:
+- contract shape, validation, versioning, auth, errors, pagination, idempotency, downstream coupling.
+
+Security:
+- trust boundaries, public exposure, authentication, authorization, secret handling, PII/data classification, replay/abuse/rate limiting.
+
+Observability:
+- logs, metrics, traces, SLOs, correlation, dependency health, saturation/queue depth, evidence gaps.
+
+Testing:
+- unit/integration/contract/e2e boundaries, failure-path coverage, architecture risks not currently exercised.
+
+Deployment:
+- artifact/process/container topology, environment/config boundaries, health/readiness, scaling, rollout/rollback, region/failure-domain assumptions.
+
+Treat missing evidence as a learning question, not a defect by itself.
+
+## 12. Architecture evolution and counterfactuals
+
+Use the current system as the baseline and explore changes such as:
+
+```text
+remove the cache
+make a synchronous path asynchronous
+increase traffic 10x/100x
+move from SQLite to a server database
+introduce multi-region requirements
+split or recombine a service
+add a queue/search/object store/CDN
+tighten latency/availability/privacy requirements
+```
+
+For each evolution:
+
+```text
+problem/evidence
+→ change
+→ expected benefit
+→ new complexity/failure modes
+→ migration path
+→ when NOT to do it
+```
+
+Prefer evolutionary design over cargo-cult complexity.
+
+## 13. Tradeoff and "why not?" drills
+
+Challenge choices with credible alternatives:
+
+```text
+Why not a monolith?
+Why not microservices?
+Why not Kafka/a queue?
+Why not synchronous HTTP?
+Why not cache this?
+Why not shard now?
+Why not retry here?
+Why not use the existing relational database?
+```
+
+The goal is to defend the simplest design that satisfies current constraints, then adapt when constraints materially change.
+
+## 14. Architecture decisions
+
+When ADRs or documented decisions exist, connect diagram components/edges to them. For each major choice discuss:
+
+```text
+context
+chosen decision
+alternatives
+tradeoffs
+consequences
+revisit trigger
+```
+
+Do not silently create durable ADRs in learning mode.
+
+## 15. Change-focused learning
+
+`/system-lab changes <work-item>` should focus on the accepted/delivered change set when evidence is available.
+
+Show:
+
+- added/removed/changed components and dependencies;
+- affected runtime/data/message paths;
+- newly introduced or materially changed failure modes;
+- new security/observability/performance/testing questions;
+- architecture decisions or assumptions worth explaining.
+
+A changed file is evidence that a component was touched, not proof that its runtime behavior changed. Keep that distinction visible.
+
+## 16. Interview mode
+
+Make the human drive:
+
+```text
+requirements
+→ constraints + scale assumptions
+→ API/contracts
+→ data/storage
+→ high-level architecture
+→ deep dive
+→ bottleneck/failure analysis
+→ consistency/reliability
+→ security/observability
+→ evolution
+→ tradeoff defense
+```
+
+Perturb one material constraint at a time: 20x traffic, multi-region, strict data residency, unreliable dependency, tighter p99, zero-downtime migration, duplicate delivery, cost pressure, or new abuse threat.
+
+Score/coach the independent system-design competencies rather than assigning one generic score.
+
+## 17. Cross-lab navigation
+
+System Lab owns system context; Database Lab owns schema/query/ORM/plan depth.
+
+When a system node represents a database, explicitly offer `/db-lab` for deeper relational/query evidence. When `/db-lab` reaches system-level concerns such as service boundaries, traffic, availability, or end-to-end runtime flow, offer `/system-lab`.
+
+Do not duplicate database internals inside System Lab or architecture reasoning inside Database Lab.
+
+## 18. Delivery-completion visibility
+
+After successful delivery, Project Forge may recommend the labs as optional learning while the change is fresh.
+
+- If database-related evidence changed, make `/db-lab` or `/db-lab changes <work-item>` visibly recommended.
+- If architecture/runtime/API/messaging/deployment/security/observability behavior changed, make `/system-lab` or `/system-lab changes <work-item>` visibly recommended.
+- If neither is especially relevant, the labs may remain visible as available options without claiming the ticket changed them.
+- Never use user-facing wording such as "rebuild the diagram" or "refresh the database model". Running a lab already means inspect current evidence and generate the current view.
+- Best-effort disposable artifact generation after delivery is allowed when safe and cheap, but failure to generate a learning artifact never changes delivery state.

package/assets/generated/core/core/skills/tear-down/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: tear-down
+description: "Guided destructive cleanup for local state, one exact repository-defined named environment, or all explicitly configured POC environments. Preserves ownership boundaries and resolved Production-data authorization."
+argument-hint: "[local|<environment>|all]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Tear Down
+
+`/tear-down` is the human-facing destructive cleanup workflow for repository-owned POC state.
+
+Logical environment names are data-driven and are not limited to Staging/Production:
+
+```text
+/tear-down demo
+/tear-down qa
+/tear-down staging
+/tear-down prod-east
+```
+
+The skill owns exact scope selection, read-only preflight, destructive preview, and Human-in-the-Loop authorization. Repository-provided deterministic tooling owns deletion mechanics.
+
+## 1. Resolve exact project topology
+
+Prefer:
+
+```text
+DEPLOYMENT_TOPOLOGY.json
+```
+
+Use `PROJECT_BOOTSTRAP.json` deployment topology only as the initial topology fallback.
+
+Resolve only configured logical environments and their current purpose/Production classification, placement/target binding, repository/application identity, and ownership evidence.
+
+If `demo` is configured, `/tear-down demo` means exactly `demo`. If `prod-east` has purpose `production`, it remains Production-class regardless of its literal name.
+
+Never guess a similar environment and never widen scope after failure.
+
+## 2. Select exact destructive scope
+
+```text
+local
+<one exact repository-defined named environment>
+all
+```
+
+If no scope is named, present only scopes the repository actually supports; never silently default to a Production environment or `all`.
+
+`all` means only all explicitly configured scopes for this POC; it never means machine-wide cleanup.
+
+Selecting scope does not authorize deletion. Physical colocation never merges ownership: deleting `demo` must not remove `staging` or `prod-east` merely because they share hardware.
+
+If the requested name is absent from project topology, stop. Do not substitute another environment.
+
+## 3. Resolve Production classification from the deletion set
+
+For each selected environment identify:
+
+```text
+environment name
+purpose / Production classification
+placement / target
+repository/application identity
+ownership markers required by installed tooling
+```
+
+For current Deployment Kit consumers, custom Production names may be passed explicitly, for example:
+
+```text
+--production-environment prod-east
+```
+
+Use actual installed help/version evidence. If the installed tool cannot preserve a custom Production classification, stop rather than downgrading the destructive gate.
+
+## 4. Present an exact destructive preview
+
+Show what will be removed and what will be preserved.
+
+```text
+TEAR-DOWN READY
+
+Scope: <local|demo|qa|staging|prod-east|all>
+Repository/app: <verified identity>
+Selected environments:
+  <name> → <placement/target> — <purpose/classification>
+
+Will remove:
+  <only tool-owned resources for exact selected scopes>
+
+Will preserve:
+  <shared/unrelated environment and platform resources>
+```
+
+Do not promise deletion of named/shared Docker volumes unless the installed deterministic contract proves exact ownership and explicitly includes them. Do not promise deletion of any shared/unrelated resource whose ownership cannot be proven.
+
+## 5. Authorization gates
+
+Every modifying tear-down requires the installed normal authorization, conceptually:
+
+```text
+[POC TEAR DOWN]
+```
+
+whenever **any selected environment is Production-class**, require the stronger Production-data deletion authorization, conceptually:
+
+```text
+[PRODUCTION DATA DELETE]
+```
+
+Resolve exact phrases from the installed tool/version. Do not tie the Production-data gate only to literal scope strings such as `production` or `all`; it depends on the actual resolved deletion set.
+
+A prior `/setup`, environment proof, `/deploy`, merge, CI, or other approval never authorizes destructive cleanup.
+
+If identity, selected environment set, classification, binding, ownership evidence, or deletion set changes after preview, require renewed review/authorization.
+
+## 6. Execute only repository-provided deterministic cleanup
+
+After authorization, invoke only the approved tear-down command with exact named scopes/bindings. Do not improvise shell commands.
+
+For a generalized current Deployment Kit invocation, exact bindings may look conceptually like:
+
+```text
+--environment-target demo=<target>
+--environment-target staging=<target>
+--environment-target prod-east=<target>
+--production-environment prod-east
+```
+
+Use the installed contract rather than inventing flags for older versions.
+
+Never add machine-wide Docker prune, shared platform/network removal, unrelated environment cleanup, host reprovisioning, target rebinding, credential/trust deletion, or registry-package deletion unless a separate lifecycle operation explicitly owns and authorizes it.
+
+If aggregate `all` cleanup stops partway, report completed and remaining scopes. Do not manually compensate by deleting the rest.
+
+## 7. Verify and report outcome
+
+Use repository-provided status/evidence commands when available. Report only observed evidence: requested scope, exact environment names/targets processed, Production-class environments included, local state processed, removed versus already-absent resources, and any remaining scopes after a partial stop.
+
+When the installed deterministic contract is idempotent, already-absent owned resources should remain safe to re-check/re-run without broadening scope.

package/assets/generated/core/core/skills/upstream-fix/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: upstream-fix
+description: Route reusable bugs discovered in a consumer to the canonical shared repository, allow bounded upstream implementation, and return adoption through the consumer's actual provenance/update boundary.
+argument-hint: "[optional problem summary]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Upstream Fix
+
+`/upstream-fix` is for a problem discovered while working in a consumer repository when the likely owner is shared Project Forge code rather than consumer product code.
+
+The governing rule is:
+
+```text
+discover in consumer
+→ diagnose/prove in consumer
+→ fix in owning canonical repository
+→ deliver there
+→ adopt through the consumer's recorded distribution boundary
+→ verify again in consumer
+```
+
+A temporary edit to a shared-managed file inside a consumer may be useful as diagnosis/proof, but it is never the canonical delivered fix.
+
+## 1. Invocation authorization
+
+Invoking `/upstream-fix` authorizes:
+
+- read-only ownership/provenance inspection in the consumer;
+- classification to the smallest canonical owner;
+- inspection of already-available local canonical repository candidates;
+- when ownership and the bounded patch are clear and a canonical checkout is safe, routine creation/use of one short-lived canonical work branch and application of only that bounded fix plus focused tests/docs.
+
+Invocation does **not** authorize commit, push, PR creation, merge, release publication, package publication, deployment, rewriting/discarding consumer work, or changing multiple canonical repositories in one bounded fix.
+
+Normal review and `/deliver` occur later while focused on the owning canonical repository.
+
+## 2. Establish consumer provenance
+
+From the consumer root inspect, when present:
+
+- `PROJECT_FORGE_BASELINE.json`;
+- `CORE_BASELINE.json`;
+- `DEPLOYMENT_BASELINE.json`;
+- `.github/project-forge-workspace.json`;
+- current Git branch/status/diff;
+- the files involved in the reported problem or temporary proof.
+
+Run repository-local managed-baseline checks when available.
+
+Do not assume every generated-looking file is shared-owned. Use baseline managed-path records as the primary ownership evidence, and use `PROJECT_FORGE_BASELINE.json` to determine whether component baselines are managed together by an umbrella package.
+
+## 3. Classify the owner
+
+Use the smallest owning layer that would need the same fix for another consumer.
+
+### Consumer-owned
+
+Application domain logic, UI behavior, app-specific configuration, product tests, and consumer architecture normally remain consumer-owned.
+
+Result:
+
+```text
+CONSUMER FIX
+Owner: current repository
+```
+
+Return to the consumer's normal `/start-work` / implementation / review / `/deliver` flow.
+
+### Core-owned
+
+Evidence includes a path managed by `CORE_BASELINE.json` or behavior defined by reusable Core workflow assets.
+
+```text
+CORE BUG
+Owner: <repository recorded by CORE_BASELINE.json>
+```
+
+### Deployment-Kit-owned
+
+Evidence includes a path managed by `DEPLOYMENT_BASELINE.json` or reusable deployment mechanics owned by that recorded Kit.
+
+```text
+DEPLOYMENT BUG
+Owner: <repository recorded by DEPLOYMENT_BASELINE.json>
+```
+
+### Package assembly / Project Forge Platform-owned
+
+When canonical component source is correct but the published package bytes, component pins, package engine, or umbrella baseline behavior is wrong:
+
+```text
+PROJECT FORGE PLATFORM BUG
+Owner: package/platform repository supported by evidence
+```
+
+### Generator/control-plane owned
+
+If the package payload is correct but generation/publication/orchestration materializes it incorrectly, classify Bootstrap/control-plane ownership from evidence rather than patching a generated consumer.
+
+If ownership is genuinely ambiguous, stop at `UPSTREAM OWNER UNCLEAR`. Do not write to multiple repositories speculatively.
+
+## 4. Temporary consumer proof
+
+A temporary consumer edit to a shared-managed path is allowed for diagnosis when it proves the fix in real application context.
+
+Report it explicitly:
+
+```text
+TEMPORARY SHARED-MANAGED PROOF
+Consumer path: <path>
+Canonical owner: <repo>
+Do not deliver this consumer copy.
+```
+
+Do not silently discard the proof and do not stage/commit it as ordinary consumer implementation.
+
+## 5. Resolve a safe canonical checkout
+
+For the classified owner consider, in order:
+
+1. an explicit path supplied by the human;
+2. an already-open workspace folder with the expected Git remote;
+3. a normal sibling checkout derived from the canonical repository name.
+
+Do not broadly scan the filesystem and do not clone automatically merely to continue.
+
+A candidate is safe only when it is the expected repository, has no merge/rebase/cherry-pick in progress, has no unrelated local work, and does not require stash/reset/rebase/force/discard operations.
+
+## 6. Port the bounded fix upstream
+
+When a safe canonical checkout exists and the equivalent reusable fix is clear:
+
+1. inspect canonical implementation/tests before editing;
+2. create/use one repository-appropriate short-lived branch;
+3. reproduce the root cause canonically where practical;
+4. apply the reusable fix without consumer-specific names/configuration;
+5. add/update focused tests that would have caught the defect;
+6. update canonical docs when the contract changed;
+7. run relevant local checks;
+8. show the meaningful canonical diff and observed validation.
+
+If the consumer proof cannot be generalized safely, stop and reclassify rather than forcing it upstream.
+
+## 7. Handoff to canonical delivery
+
+When the upstream implementation is ready:
+
+```text
+UPSTREAM FIX READY
+
+Owner: <canonical repo>
+Branch: <branch>
+Consumer proof: <path/status>
+Validation: <observed checks>
+Next: focus the canonical repository and run /deliver
+```
+
+`/upstream-fix` does not commit/push/open/merge the canonical PR itself.
+
+## 8. Adopt the accepted fix through the right boundary
+
+After the canonical PR is merged and required default-branch CI is green, re-read the consumer provenance before choosing adoption.
+
+### Package-managed consumer (`PROJECT_FORGE_BASELINE.json` present)
+
+Do **not** direct-sync Core or Deployment Kit into the consumer.
+
+The accepted component fix must first become part of an accepted published Project Forge package:
+
+```text
+canonical Core/Deployment fix merged
+→ Project Forge Platform pins the exact accepted component commit
+→ Project Forge Platform PR + CI
+→ explicit package publication gate
+→ published exact @mriekki/project-forge version
+→ consumer /project-forge-update <version>
+```
+
+Until that package exists, report:
+
+```text
+PACKAGE RELEASE REQUIRED
+Consumer adoption is blocked on a Project Forge package that contains the accepted upstream commit.
+```
+
+Do not silently patch `PROJECT_FORGE_BASELINE.json`, `CORE_BASELINE.json`, or `DEPLOYMENT_BASELINE.json` to pretend the package contains the new component.
+
+### Component-only Core consumer (`PROJECT_FORGE_BASELINE.json` absent)
+
+A Core-owned fix may return through `/core-sync` using the exact accepted Core commit/distribution.
+
+### Component-only Deployment consumer (`PROJECT_FORGE_BASELINE.json` absent)
+
+A Deployment-owned fix may return through the canonical Deployment Kit component sync and refresh `DEPLOYMENT_BASELINE.json`.
+
+### Generator/control-plane fix
+
+Validate through that platform's canonical regeneration/update path, never by manually editing generated managed files.
+
+Then rerun the original reproduction and baseline checks in the consumer.
+
+## 9. Consumer delivery guard
+
+If `/deliver` is invoked in a consumer with unexplained Core-, Deployment-, or Project Forge-package-managed drift, stop before staging/commit/push. Route reusable managed-file changes through `/upstream-fix` and then through the appropriate accepted update boundary.
+
+Consumer-owned changes may be delivered normally when managed baselines are clean.
+
+## 10. Boundaries
+
+`/upstream-fix` never:
+
+- merges changes;
+- publishes releases/tags/packages;
+- deploys production;
+- commits one bounded fix across multiple repositories;
+- auto-stashes, resets, rebases, force-pushes, or discards work;
+- requires ordinary consumer users to clone shared repositories;
+- treats a temporary managed consumer edit as a permanent fork;
+- bypasses `PROJECT_FORGE_BASELINE.json` with component-only sync.