docs(rules): log a bottleneck as a Problem and design it out

docs/rules/DEV-155.md

@@ -0,0 +1,35 @@
+---
+id: DEV-155
+title: "Log a Bottleneck as a Problem and Design It Out"
+status: "active"
+enforcement: "manual"
+severity: "error"
+depends_on: ["DEV-150"]
+---
+
+## Problem
+
+When work depends on one person to proceed, that person becomes a bottleneck.
+The team scales by adding faces rather than a system, and progress stalls when
+that person is unavailable. Left implicit, the bottleneck is never owned or
+removed.
+
+## Solution
+
+Treat a bottleneck as a barrier to the goal and route it through the same
+Problem workflow as any other blocker.
+
+1. When a step repeatedly depends on one person to proceed, name it as a barrier
+   per [DEV-150](./DEV-150.md).
+1. Open it as a Problem per [DEV-160](./DEV-160.md), stating what the team
+   cannot do while the dependency stands.
+1. The Solution designs the dependency out: a shared framework, delegated
+   bounds, or automation, so the work proceeds without that person in the loop.
+1. Scale by building the system, not by adding people to absorb the load.
+
+### Acceptance Criteria
+
+- [ ] A recurring single-person dependency is recorded as a Problem
+- [ ] The Problem states what the team cannot do while the dependency stands
+- [ ] The Solution removes the dependency, not just adds capacity
+- [ ] Nothing requires that one person once the Problem is resolved

docs/rules/README.md

@@ -35,6 +35,7 @@ Solution, Spec.
 - [DEV-130](./DEV-130.md): understand and agree the Spec first
 - [DEV-140](./DEV-140.md): give an ETA once the goal is clear
 - [DEV-150](./DEV-150.md): map every barrier blocking the goal
+- [DEV-155](./DEV-155.md): log a bottleneck as a Problem and design it out
 - [DEV-160](./DEV-160.md): write a clear Problem statement
 - [DEV-170](./DEV-170.md): deliver work as a pull request
 - [DEV-180](./DEV-180.md): keep the Spec as unimplemented behavior and graduate