ty checking

docs/skills/pytest-scaffolding/SKILL.md

@@ -73,6 +73,19 @@ These are stable defaults regardless of stack:
 4. Register markers up front (`unit`, `integration`, `smoke`, `slow`, `external`) and keep strict marker checks enabled.
 5. Separate fast feedback (`-m unit`) from broader integration/external lanes.
 6. Validate structure early with collection checks before expanding assertions.
+7. Prefer behavior-first tests that exercise real code paths and concrete inputs over patching internals.
+8. Use monkeypatching, mocks, and fakes extremely sparingly, only when no practical real-input alternative exists, and only after explicit user confirmation.
+
+## Universal Test Double Policy (Repo-Local Placement)
+
+Treat this policy as universal guidance for test authoring, while it is documented in this repository-local skill file for now.
+
+Apply this policy whenever a test change introduces a fake collaborator or patched behavior:
+
+1. Attempt a real-input, real-object test design first.
+2. If that approach is impractical, explain why and request user confirmation before adding monkeypatching, mocks, or fakes.
+3. Keep any approved test double narrowly scoped and document the exact boundary it replaces.
+4. Revisit approved test doubles when implementation seams improve so they can be removed.
 
 ## Stack-Specific Guidance
 
@@ -89,6 +102,7 @@ Primary upstream docs are curated in each reference page. Start with:
 3. Pytest markers: [marker examples](https://docs.pytest.org/en/stable/example/markers.html)
 4. FastAPI testing: [FastAPI testing tutorial](https://fastapi.tiangolo.com/tutorial/testing/)
 5. SQLAlchemy transaction testing: [SQLAlchemy external transaction pattern](https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#joining-a-session-into-an-external-transaction-such-as-for-test-suites)
+6. Pytest monkeypatch usage and limits: [monkeypatch how-to](https://docs.pytest.org/en/stable/how-to/monkeypatch.html)
 
 ## Quick Validation Commands
 
@@ -108,3 +122,4 @@ When this skill is applied, return:
 5. Exact validation commands.
 6. Relevant source-doc links for any non-trivial recommendation.
 7. Risks, assumptions, or open questions.
+8. Explicit confirmation status if monkeypatching, mocks, or fakes were requested or used.