Drivers

Drivers, projected from driver entities. Edit a driver entity and regenerate.

Id	Title	Summary
A long-lived, harness-agnostic substrate	A long-lived, harness-agnostic substrate	Keeping all state as plain markdown + frontmatter in git — no database, no parallel source of truth — means the project’s record outlives any tool that operates it. A human can read it, git can version it, and a future CLI or web UI is just a materialized view. Betting on a legible, durable substrate is leverage against tool churn.
Capture a stray idea without breaking flow	Capture a stray idea without breaking flow	Mid-work, an idea or friction surfaces. The user wants to jot it in one line and keep going, trusting it becomes a tracked, triageable item — not lose it to a scratch file or a derailed train of thought.
Keep the project moving hands-off	Keep the project moving hands-off	A maintainer wants to start one command and have the project keep moving on its own: ready work picked up, PRs shepherded through review and conflicts, merged tasks closed out — converging overnight without manual scheduling, and surfacing only what genuinely needs a human.
No single, discoverable command surface	No single, discoverable command surface	Functionality shipped as per-capability scripts and ad-hoc helpers has no single discoverable entry point and no convention for where the “turn freeform input into an action” step runs — a user can’t type one command and see what the system can do. The sdlc <noun> <verb> CLI now answers this; the driver holds for any capability that ships outside that tree.
No traceability from intent to verification	No traceability from intent to verification	A task is justified only by itself: there is no record of the motivation it serves or the measurable outcome it advances, and “done” means a merged PR rather than a declared, testable condition. You can’t walk from a unit of work up to its why or down to its proof.
Operate the same capability from shell, CI, or a Claude session	Operate the same capability from shell, CI, or a Claude session	The same capability should run from a plain shell, from CI, and from inside a Claude session — without reimplementing it per context. The effect must be reproducible and testable, while freeform input can still be interpreted when a human-friendly front door is wanted.
Parallel work collides — ids and uncoordinated claims	Parallel work collides — ids and uncoordinated claims	Work happens on many branches and across many agents at once. Two hazards follow: sequential per-prefix ids collide when branches each mint “the next” id for different entities, and nothing stops two actors picking up the same task. Without a coordination primitive, parallel work corrupts shared state.
Self-host: the tool dogfoods its own entity model	Self-host: the tool dogfoods its own entity model	SDLC can describe its own development with its own machinery: the milestones, tasks, decisions, and capabilities that plan the tool are themselves entities validated by the tool’s own contract. Self-hosting is leverage — every improvement to the model immediately improves how the project runs itself, and the model is exercised by real use the day it ships.
Take an idea to merged code through named operations	Take an idea to merged code through named operations	A user wants to drive a single task from “this should exist” to “merged code that delivers it” by walking it through a staged lifecycle, where each transition is a named operation invokable from a Claude session and defers to deterministic code where it has hardened. The user steps in only where judgment is required.
The lifecycle is human-driven at every junction	The lifecycle is human-driven at every junction	Moving work forward requires a human at every junction: invoke the next operation, notice a PR merged, tear down a worktree, sync main. Nothing keeps the loop running on its own, so progress stalls whenever attention lapses, and drift compounds with every merge.
The orchestrator needs the next N parallel-safe tasks	The orchestrator needs the next N parallel-safe tasks	The SDLC orchestrator must repeatedly choose which tasks to start next: those in open/ready status whose depends_on prerequisites are all satisfied, capped at max_implementations, and held under per-category in-flight limits. Today this readiness-and-cap computation is hand-rolled inside the orchestrate skill; it wants a reusable engine that, given the task graph and current statuses, returns the next N parallel-safe tasks.

Emerging / retired:

Id	Title	Summary	Status
Goal-directed readiness and blocker introspection	Goal-directed readiness and blocker introspection	Beyond “what is runnable anywhere,” the orchestrator and its users want goal-directed readiness: the next N tasks that actually advance a chosen milestone, and — when nothing advances it — which unfinished prerequisites block it. The global frontier scatters effort; a goal-directed frontier focuses it and turns “why is this milestone stuck?” into a query.	open/proposed
Headless scripts need the intersecting file set for a working scope	Headless scripts need the intersecting file set for a working scope	A headless script (an agent run, a batch job, a CI step) is most useful when it starts from the right slice of the repository. That slice is usually expressed as patterns — “everything under src/api/** and the matching tests” — and the caller wants the concrete paths that fall in the intersection of a working scope and a candidate set, to hand the model as context. Today there is no primitive that answers “which of these paths / patterns fall inside this scope”; each caller re-implements ad-hoc string matching.	open/proposed
No embeddable TS library answers “what’s runnable now” with rules	No embeddable TS library answers “what’s runnable now” with rules	No TypeScript library answers: given a dependency graph and node statuses, what is runnable now — with pluggable eligibility rules, priority ordering, and goal-direction? Python’s graphlib.TopologicalSorter offers a bare get_ready() / done() frontier and nothing else; the engines that do more (Airflow, Dagster, Prefect) are heavyweight runtimes, not embeddable libraries. There is room for a small, embeddable piece that fills the gap.	open/proposed
No TS library answers “do these two globs intersect?” — an extractable niche	No TS library answers “do these two globs intersect?” — an extractable niche	The overlap primitive SDLC needs is missing from the JavaScript/TypeScript ecosystem. Every mainstream matcher — minimatch, micromatch, picomatch, globset — answers only “does this concrete path match this pattern?” The one directly on-point package, glob-intersection, is immature and deliberately over-permissive (it reports false-positive overlaps). The clean automata engine that does answer it, greenery, is Python. A correct, well-scoped TypeScript intersects(a, b) is a genuine niche — useful well beyond SDLC, and a natural OSS extraction.	open/proposed
Predict edit conflicts by testing whether two work items’ path-claims overlap	Predict edit conflicts by testing whether two work items’ path-claims overlap	Two work items that touch the same files will collide at merge. If each item declares the paths it is likely to touch — as globs, not a fixed file list — then two items probably conflict when their claimed pattern sets overlap. Answering “do src/api/** and src/**/handler.ts share any common path?” is a pattern-vs-pattern overlap question, distinct from the after-the-fact “do these concrete changed files hit a reserved pattern?” that git hooks already do.	open/proposed
Resolve which pattern-declaring artifacts apply to a working scope	Resolve which pattern-declaring artifacts apply to a working scope	Guideline, standard, and policy files each declare the path patterns they govern — a general UI guideline for **/*.{vue,html,jsx}, a Vue-specific one for **/*.vue, an API guideline for src/api/**. Before an agent acts, it needs the subset of those artifacts that apply to where it is about to work, whether that scope is given as a file, a set of target files, a set of patterns, or a directory. The applicable set must be computed from patterns alone — the target files need not exist yet (“I am going to be working in src/siteA/components/”). The result should preserve the guidelines’ declared order so the caller can infer a prioritization (general before specific, or a last-wins rule).	open/proposed