docs(adr): T-036 §2.2 intake promotion gate vs artifact-driven phase gates

docs/adrs/T-036-artifact-driven-gate-parametrization.es.md

@@ -59,6 +59,16 @@ flowchart TD
 
 **Regla de oro:** *Si el Core no define artefactos para una fase, Tracker no permite evidencia ni criterios de gate ahí — no hay nada que parametrizar.*
 
+### 2.2 Intake es un gate de promoción, no de deliverables
+
+Las oportunidades / la etapa de intake **no llevan restricciones de evidencia ni de artefactos deliverable**. El "gate" de intake es el **gate de promoción (opportunity → initiative)**: su única parametrización son los **criterios/reglas que el tenant define y que una oportunidad debe cumplir para promoverse a iniciativa**, evaluados sobre los **campos del registro opportunity**. Ese es el punto de personalización del tenant en intake.
+
+Desde las **fases de la iniciativa en adelante** (discovery → design → construction → qa → release), el gate es **dirigido por artefactos** (§2): evidencia requerida = artefactos deliverable del Core de la fase; los criterios evalúan **los campos de esos artefactos**.
+
+Por tanto la fuente del `artifactType` de los criterios depende de la fase:
+- **Intake** → `opportunity` (el registro; reglas de promoción). Sin evidencia deliverable; el guard "sin artefactos Core ⇒ sin criterios" **no** aplica aquí.
+- **Phase gates** → los artefactos deliverable del Core de la fase (PRD, blueprint, test-results…). El guard sí aplica.
+
 ### 2.1 GateMode es DERIVADO, no editable (decisión Opción A)
 
 `GateMode` (SIMPLE/COMPLEX) se **calcula desde la política efectiva**, nunca es un toggle que fija el tenant:
@@ -81,7 +91,7 @@ Nunca una pregunta libre de "escribe un tipo de evidencia".
 
 **4 — Campos custom del tenant sin romper el estándar Core.** `ArtifactFieldSchema` conserva `baseFields[]` (Core, inmutables, read-only) + `customFields[]` (tenant, `custom.<name>`). Reglas: un custom field solo puede declararse **si el artefacto existe en el perfil Core de la fase**; los nombres custom viven en el namespace `custom.` (sin colisión con baseFields ni entre sí).
 
-**5 — Criterios de evaluación sobre campos.** `EvaluationCriterion { artifactType, fieldPath, operator, expected[], severity }`. `artifactType` se **elige** de los artefactos Core de la fase; `fieldPath` se **elige** de `baseFields ∪ customFields` de ese artefacto (dropdowns, no texto libre). Los operadores se restringen por el `dataType` del campo. `blocking` no cumplido → falla el gate; `advisory` → solo se registra.
+**5 — Criterios de evaluación sobre campos.** `EvaluationCriterion { artifactType, fieldPath, operator, expected[], severity }`. `artifactType` se **elige** — en **intake** queda fijo a `opportunity` (reglas de promoción sobre el registro opportunity, §2.2); en **phase gates** se elige de los artefactos deliverable del Core de la fase. `fieldPath` se **elige** de `baseFields ∪ customFields` del artefacto elegido (dropdowns, no texto libre). Los operadores se restringen por el `dataType` del campo. `blocking` no cumplido → falla el gate; `advisory` → solo se registra.
 
 **6 — Validaciones que impiden config inválida.** En el **dominio** (invariantes del agregado) *y* reflejadas en la UI (deshabilitar/ocultar) — la integridad es responsabilidad de la capa de aplicación (sin FK cross-agregado, T-028):
 

docs/adrs/T-036-artifact-driven-gate-parametrization.md

@@ -59,6 +59,16 @@ flowchart TD
 
 **Rule of gold:** *If Core defines no artifacts for a phase, Tracker allows no evidence and no gate criteria there — there is nothing to parametrize.*
 
+### 2.2 Intake is a promotion gate, not a deliverable gate
+
+Opportunities / the intake stage carry **no evidence or deliverable-artifact restrictions**. The intake "gate" is the **promotion gate (opportunity → initiative)**: its only parametrization is the **tenant-defined criteria/rules an opportunity must satisfy to be promoted to an initiative**, evaluated over the **opportunity record's fields**. This is the tenant's customization point at intake.
+
+From **initiative phases onward** (discovery → design → construction → qa → release) the gate is **artifact-driven** (§2 above): required evidence = the phase's Core deliverable artifacts; criteria evaluate **those artifacts' fields**.
+
+Consequently the criteria `artifactType` source is phase-dependent:
+- **Intake** → `opportunity` (the record; promotion rules). No deliverable evidence; the "no Core artifacts ⇒ no criteria" guard does **not** apply here.
+- **Phase gates** → the phase's Core deliverable artifacts (PRD, blueprint, test-results…). The guard applies.
+
 ### 2.1 GateMode is DERIVED, not editable (per the Option-A decision)
 
 `GateMode` (SIMPLE/COMPLEX) is **computed from the effective policy**, never a tenant-set toggle:
@@ -81,7 +91,7 @@ Never a free "type an evidence type" prompt.
 
 **4 — Tenant custom fields without breaking the Core standard.** `ArtifactFieldSchema` keeps `baseFields[]` (Core, immutable, read-only) + `customFields[]` (tenant, `custom.<name>`). Rules: a custom field may only be declared **if the artifact exists in the phase's Core profile**; custom names live in the `custom.` namespace (no collision with baseFields or each other).
 
-**5 — Evaluation criteria on fields.** `EvaluationCriterion { artifactType, fieldPath, operator, expected[], severity }`. `artifactType` is **picked** from the phase's Core artifacts; `fieldPath` is **picked** from `baseFields ∪ customFields` of that artifact (dropdowns, not free text). Operators are constrained by the field `dataType`. `blocking` unmet → fails the gate; `advisory` → recorded only.
+**5 — Evaluation criteria on fields.** `EvaluationCriterion { artifactType, fieldPath, operator, expected[], severity }`. `artifactType` is **picked** — at **intake** it is fixed to `opportunity` (the promotion rules on the opportunity record, §2.2); at **phase gates** it is picked from the phase's Core deliverable artifacts. `fieldPath` is **picked** from `baseFields ∪ customFields` of the chosen artifact (dropdowns, not free text). Operators are constrained by the field `dataType`. `blocking` unmet → fails the gate; `advisory` → recorded only.
 
 **6 — Validations that prevent invalid configuration.** Enforced in the **domain** (aggregate invariants) *and* mirrored in the UI (disable/hide) — integrity is an application-layer responsibility (no cross-aggregate FK, per T-028):