Merge pull request #34 from eduralph/docs/lane-identity-and-pool-size

docs(09): state lane-identity + pool-size rules for the in-driver pool

Author: eduralph

template/PCDA/quality-cycle/09-parallel-lanes.md

@@ -78,6 +78,10 @@ The fan-out can be realized two ways, and they trade off cleanly:
 
   The harness owns the *concurrency and the lane id*; it does **not** own the project's checkout or runner, so the actual isolation stays **[project-provided]**: a gate that applies/reverts a target checkout, or starts a container / binds a port / writes a scratch dir, must name that resource by `$PDCA_LANE` (e.g. a `repo-lane$PDCA_LANE` checkout, `--name app-l$PDCA_LANE`, `port = 8000 + $PDCA_LANE`) — exactly the "name runner artifacts uniquely per lane" rule above, now keyed off a harness-supplied slot. Because a worker reuses its slot across the bundles it pulls, only N copies are ever needed, not one per bundle. (Publish is unaffected — it runs in the serial join, so its checkout is never contended and needs no lane scoping.)
 
+  **The lane is the worker's, not the bundle's.** A worker reads its *own* slot at the moment it runs a gate and passes it down as `$PDCA_LANE`; the slot is held in worker-local state and is **never written into the bundle** (`results/issue_<id>/`). So a bundle is not bound to a lane — re-run it and it may land on a different slot — which is sound precisely because a lane scopes only *disposable* shared resources (the checkout it patches then reverts, a container, a scratch dir), never anything the bundle persists. The serial driver (`lanes = 1`) pins no slot, so gates receive no `$PDCA_LANE` and run exactly as a single run does. A gate therefore needs no notion of "which lane am I" beyond reading `$PDCA_LANE` (absent ⇒ serial ⇒ the shared resource).
+
+  **Pool size — how many lanes.** `lanes` is floored at 1 (the serial driver) and has **no hard ceiling**; the driver runs `min(lanes, bundles-in-flight)` workers, so configuring more lanes than there are bundles simply leaves the extra idle. The real bound is the **host**: each live lane is a full concurrent Check gate-suite (its own runner container) plus the lane's builder/reviewer model calls, so the ceiling is set by CPU/RAM for concurrent gates and by the shared **model-API rate limit** — tune per host, not a fixed number. One precondition the project owns: the N lane-private resources for slots `0..N-1` must **exist before the run** (the per-lane checkouts/worktrees/ports created up front to match the chosen N); a worker pinned to a slot whose resource is missing fails loudly — which the refuse-on-dirty / missing-resource guards are there to surface.
+
   **Combine + re-gate** stays external and composes from existing [built] pieces: drive each lane's bundles into a per-lane bundle root if you want them separated (`PDCA_BUNDLE_ROOT`), then an external script merges the accepted lane branches and runs the repo-scoped merge re-gate (`pdca gates --working-tree`) over the combined tree (§Integration validation). The harness ships no lane-merge orchestrator — that's a project script over these primitives.
 
 Start with separate workspaces (it works today with the generic mechanics above); reach for the in-driver pool only when per-lane disk or sign-off ergonomics actually bite.