git:20261007.27e06ab to git:20261010.f1b89f6

---

name: tech-selection

description: >-

argument-hint: "<decision to make>"

---

# Tech Selection — Gated Checklist

A checklist for choosing between technologies, not a scoring rubric. The core

insight: these criteria are **filters, not sorters** — they kill candidates that

Two outcomes end the protocol early:

## Not This

- Not for research reports (use deep-research), debugging or bug fixes in already-settled code, or price comparisons between vendors — none of these is choosing a technology.

- Not an interview framework — the user delegates implementation, not direction. Don't ask "which do you prefer" when you can probe and decide.

- Not a scoring rubric — no weighted scores, no "winner" ranking. Filters, then business anchor.

- Not self-certifying — the "why this isn't garbage" defense is written by this skill but must be independently checkable, not self-approved.

- Not a cost gate — budget sets execution tier (which model runs), never whether to do it. Don't use cost as a rejection reason for the user's own projects.

- Not a scope expander — no unrequested features, frameworks, or complexity.

- Not package-size-driven — line count and bundle size are proxies, not quality.

## Execution Protocol

### Step 0 · Frame

Write two things before comparing any candidate:

1. The **named business result** this choice serves.

2. The **named failure mode** — what observable phenomenon would prove the choice wrong.

Derive the business result from context, not from the request text. A bare "which DB" carries no result on its face — read the project's decision log, the user's recent corrections, and what this choice unblocks downstream. If no context exists to derive from, say so explicitly rather than fabricating one.

> Checkpoint: Cannot derive a business result from any available context → this is an execution task, not a selection task. Exit skill. Business result written as "tests pass" or "pipeline complete" → that's a proxy metric. Rewrite.

### Step 1 · Inventory Prior Art

Fixed order: internal/paid assets → external world-class + community solutions → build from scratch (last resort). Tag each candidate with which layer it came from.

Where to look for layer 1: existing credentials and paid-service capability catalogues, installed skills, the current repository's existing pipelines, the project's decision log, and the user's own curated favorites (run `favorites-search` first when it is installed). Do not limit layer 1 to `grep` in the current repo — that returns zero hits for paid services and skills, and a zero from a narrow search is not absence.

Layer 2 has a minimum coverage requirement: use a search tool to enumerate what exists, not memory alone. "Searched, found 2" is not coverage — name the search queries run, or state explicitly that no search tool was available and this is a memory-only inventory.

> Checkpoint: If the final recommendation falls to layer 3 (build) with no recorded reason from layers 1–2 → flag as 闭门造车. Zero hits from layer 1 must distinguish "searched by structural token" from "searched by remembered name" — the latter's zero hit does not mean absence.

**User-named candidates.** When the user names a specific option ("use Redis or Postgres?", "should we add a vector store?"), that option enters the candidate set like any other — it is subject to the same axes and the same three-value verdict. It is neither exempt from filtering (a named candidate is not a requirement) nor disposable (killing a user-named candidate requires naming the axis and the failure mode, exactly like any other). If the user named exactly two options, they are the minimum candidate set; add any layer-1 or layer-2 candidates the inventory surfaced, and say so.

### Step 2 · Probe for Evidence

For ingestion, indexing, storage or batch-data choices, load `references/batch-data-probes.md` and derive the representative cases from the actual consumer contract before comparing engines.

### Step 3 · Filter Each Candidate

Read `references/decision-axes.md`. For each candidate, give a three-value verdict per axis: `pass` / `fail` (name the failure mode) / `unknown` (needs probe).

A `fail` on a core axis kills the candidate. A `fail` on a C-class criterion from `references/scoped-criteria.md` **does not kill** — record it as a "declared preference against" note on that candidate and continue. Only core-axis failures remove a candidate from the survivor set.

> Checkpoint: `unknown` is not `pass`. A candidate carrying `unknown` **does not enter** the Step 4 survivor set. Do not output a "winner" from this step.

### Step 4 · Triage Survivors — The Core Gate

> Checkpoint: Can the output name which candidate was demoted and by which axis? If not, the gate was hollowed out.

### Step 5 · Self-Defense Slot

### Step 6 · Saturate Irreversible Surfaces

Scan for surfaces that cannot be patched after release: telemetry/events, field and export formats, external contracts, irreversible external actions. If any exist → saturate from v0. This axis is single-scenario evidence — apply it when the choice produces a released artifact, not to internal or revertible changes, and never use it to raise the standard on work that has no irreversible surface.

> Checkpoint: Explicitly list irreversible surfaces, or explicitly write "none." Silence = not checked. Revertible local changes do not trigger this step.

### Step 7 · Completion Declaration

Distinguish "I verified" from "I claim." Every done statement is followed by what was actually executed and observed.

## Output Shape

1. **Business result + failure mode** (Step 0) — the two lines.

2. **Candidate table** (Steps 1–3) — each candidate with its layer tag, its

per-axis verdict (`pass`/`fail`/`unknown`), and the probe name behind each

3. **Survivor demotion record** (Step 4) — for each demoted candidate, which

axis killed it and the named failure mode. If no candidate was demoted, say

"no candidate eliminated" and list the axes that passed everything.

4. **Decision branch** (Step 4) — declare exactly one of:

- `0 survivors` with the diagnosis (axis wrong vs candidate set incomplete)

5. **Self-defense** (Step 5) — each sentence traces to a probe or an axis

6. **Irreversible surface list** (Step 6) — the surfaces found, or the word

"none." Never omit.

### Stop 1 · Multi-candidate human tradeoff

- Each surviving candidate

- Its trade-offs (what it costs, what it gives up)

- One recommendation with reasoning

### Stop 2 · Unverified completion claim

## Agent Orchestration — Four Questions

Agent count is not preset here. Run the four questions from

`daymade-agent-discipline` and let them decide.

1. **Estimated time?** < 10 min → do it yourself. > 30 min → spawn *candidate* only; duration alone never licenses a spawn. 10–30 min → check other dimensions.

2. **Need main-session context (user preferences, multi-round feedback, nuanced decisions)?** Yes → do it yourself. No → spawn *candidate*, not automatic.

3. **Need an unbiased third party (evaluator/reviewer)?** Yes → must spawn (even if fast) — for high-risk, complex work lacking an independent mechanical referee. Ordinary tasks and small changes never auto-spawn one.

4. **Truly parallel (independent streams)?** Yes → may spawn, if current rules allow; implementation work, exclusive resources (browser, Computer Use, single-writer checkout) and private-context judgment never enter the fan-out pool. Otherwise doing it yourself is faster.

## References

| File | Read when |

|---|---|

| `references/decision-axes.md` | Step 3 — the 13 core filter axes with mechanical criteria |

| `references/batch-data-probes.md` | Step 2 — ingestion/indexing/storage correctness, growth, incremental work and recovery probes |

| `references/scoped-criteria.md` | Step 3 supplementary — 13 narrower criteria with scope labels; C-class items are preferences, not default gates |

| `references/rejection-modes.md` | Before proposing — 28 entries (16 rejection patterns + 18 anti-patterns, deduplicated) with self-test sentences |

## Boundary Quick Reference

| Boundary | Resolution |

|---|---|

| 禁绕过 vs fallback | Bypass = replacing the main path (fix scenario). Fallback = supplementary path (runtime channel). Different scenarios. |

| 预算定档 vs 资源无限 | Budget sets execution tier (which model runs). It never decides whether to do it. Different axes. |

| 不主动压缩 vs 宿主自动压缩 | During Steps 0–6, do not drop source material to save context — the candidate table and probe records stay complete. Host auto-compaction is outside this skill's control and is not a reason to pre-emptively thin the output. Different actors. |

| 饱和上报 vs 拒绝过度工程 | Saturation applies to irreversible telemetry (events, export formats, external contracts), not feature surface. Different surfaces. |