feat(workflows): enforce research checkpoints across development phases

shared/skills/implementation/integration-test-write/SKILL.md

@@ -10,11 +10,11 @@ Use when verifying behavior across a real application boundary, such as an API a
 ## Workflow
 
 1. Name the boundary under test and the production path the test must exercise. Keep unit-level details covered by unit tests.
-2. Reuse the repository's integration-test setup. Start only the services and data stores required for this behavior.
+2. Reuse the repository's integration-test setup. Before relying on external service, driver, or test-framework behavior, MUST apply the implementation checkpoint in `technical-research`. Start only the services and data stores required for this behavior.
 3. Prepare minimal isolated data and control external inputs. Prevent test runs from touching user data, shared environments, or live services.
 4. Cover a successful interaction and the failure or rejection path that matters to the change. Include transaction, retry, or cleanup behavior only when it is part of the contract.
 5. Assert persisted or externally observable outcomes, including relevant status, response, and side effects.
 6. Clean up created resources even when assertions fail. Make repeated runs safe and independent.
-7. Run the focused integration test and report required services, results, and any unavailable environment.
+7. Run the focused integration test and report required services, results, and any unavailable environment. MUST apply the verification checkpoint in `technical-research` to external contract claims; a mock or documentation excerpt cannot prove the real boundary works.
 
 Avoid turning an integration test into a full end-to-end suite when a narrower boundary proves the contract.

shared/skills/implementation/sql-write/SKILL.md

@@ -9,11 +9,11 @@ Use when writing or changing SQL statements, schema definitions, or database mig
 
 ## Workflow
 
-1. Identify the database engine and version, target schema, affected callers, and expected data shape. Inspect existing migrations and SQL style first.
+1. Identify the database engine and version, target schema, affected callers, and expected data shape. Inspect existing migrations and SQL style first. Before relying on engine-specific syntax, transaction, locking, or migration behavior, MUST apply the implementation checkpoint in `technical-research`.
 2. Parameterize values and validate any dynamic identifiers against an allowlist. Preserve tenant boundaries and authorization filters in every query path.
 3. For schema changes, consider existing rows, nullability, defaults, constraints, indexes, and deployment order. Prefer additive, backward-compatible steps when old and new application versions may overlap.
 4. Use transactions and explicit rollback or recovery steps where supported and appropriate. Estimate affected rows before broad updates or deletes.
 5. Do not execute destructive or production SQL without explicit authorization. A request to write SQL does not authorize running it against live data.
-6. Verify syntax and behavior against the intended engine, then inspect query results, migration ordering, and relevant application tests.
+6. Verify syntax and behavior against the intended engine, then inspect query results, migration ordering, and relevant application tests. MUST apply the verification checkpoint in `technical-research` to external claims; documentation cannot replace execution evidence.
 
 Report the database dialect, files or migration changed, verification, and any operational prerequisite.

shared/skills/implementation/unit-test-write/SKILL.md

@@ -10,10 +10,10 @@ Use when adding or updating tests for one isolated function, component, or decis
 ## Workflow
 
 1. Read the requirement and implementation. Identify the observable result that defines success and the boundary conditions most likely to fail.
-2. Follow the repository's existing test framework, naming, setup, and assertion style. Avoid new dependencies or fixtures when a small test can express the behavior.
+2. Follow the repository's existing test framework, naming, setup, and assertion style. Avoid new dependencies or fixtures when a small test can express the behavior. If test APIs, mocks, or expected outcomes depend on external behavior, MUST apply the implementation checkpoint in `technical-research` before encoding that assumption.
 3. Cover the normal case and the smallest meaningful set of boundary or failure cases. Include a regression case for a reported defect.
 4. Assert public behavior and useful error outcomes rather than private call order, incidental wording, or internal data layout.
 5. Keep each test deterministic. Control time, randomness, filesystem state, and external services when they affect the result.
-6. Run the focused test and report its result. Broaden verification only when shared behavior or connected components are affected.
+6. Run the focused test and report its result. MUST apply the verification checkpoint in `technical-research` to any external claims the result relies on. Broaden verification only when shared behavior or connected components are affected.
 
 Do not add tests that duplicate existing coverage or require production code to expose test-only hooks without a clear reason.