[AZ-900] Remove local .cursor/ copy — skills now live at ~/.cline/

.cursor/skills/research/references/quality-checklists.md

@@ -1,124 +0,0 @@
-# Quality Checklists — Reference
-
-## General Quality
-
-- [ ] All core conclusions have L1/L2 tier factual support
-- [ ] No use of vague words like "possibly", "probably" without annotating uncertainty
-- [ ] Comparison dimensions are complete with no key differences missed
-- [ ] At least one real use case validates conclusions
-- [ ] References are complete with accessible links
-- [ ] Every citation can be directly verified by the user (source verifiability)
-- [ ] Structure hierarchy is clear; executives can quickly locate information
-
-## Decomposition Completeness
-
-- [ ] Domain discovery search executed: searched "key factors when [problem domain]" before starting research
-- [ ] Completeness probes applied: every probe from `references/comparison-frameworks.md` checked against sub-questions
-- [ ] No uncovered areas remain: all gaps filled with sub-questions or justified as not applicable
-
-## Internet Search Depth
-
-- [ ] Every sub-question was searched with at least 3-5 different query variants
-- [ ] At least 3 perspectives from the Perspective Rotation were applied and searched
-- [ ] Search saturation reached: last searches stopped producing new substantive information
-- [ ] Adjacent fields and analogous problems were searched, not just direct matches
-- [ ] Contrarian viewpoints were actively sought ("why not X", "X criticism", "X failure")
-- [ ] Practitioner experience was searched (production use, real-world results, lessons learned)
-- [ ] Iterative deepening completed: follow-up questions from initial findings were searched
-- [ ] No sub-question relies solely on training data without web verification
-
-## Component Option Breadth
-
-- [ ] `00_question_decomposition.md` contains a Component Option Search Plan
-- [ ] Every component area was searched across simple baseline, established production, open-source, commercial/vendor, current SOTA, adjacent-domain, no-build/defer, and known-bad options where applicable
-- [ ] Every component area has at least 3 realistic candidates, or a documented explanation of why broad searches found fewer
-- [ ] Each lead candidate has official/source-of-truth evidence plus independent validation when available
-- [ ] Each component area includes at least one baseline/fallback option and at least one rejected or experimental option when possible
-- [ ] Alternative names, synonyms, and neighboring-domain terms were searched before declaring the option landscape complete
-- [ ] Licensing, runtime, platform, maintenance, and unsupported-scenario searches were performed for every lead, fallback, and rejected candidate
-
-## Mode A Specific
-
-- [ ] Phase 1 completed: AC assessment was presented to and confirmed by user
-- [ ] AC assessment consistent: Solution draft respects the (possibly adjusted) acceptance criteria and restrictions
-- [ ] Competitor analysis included: Existing solutions were researched
-- [ ] All components have comparison tables: Each component lists alternatives with tools, advantages, limitations, security, cost
-- [ ] Component options are broad: component tables include baseline, production, open-source, commercial/vendor, SOTA/research, adjacent-domain, defer/no-build, and disqualified options where applicable
-- [ ] Tools/libraries verified: Suggested tools actually exist and work as described
-- [ ] Component fit matrix completed: `06_component_fit_matrix.md` (or `06_component_fit_matrix/` if split) exists and every selected component/tool/pattern is marked `Selected`
-- [ ] No field-adjacent substitution: no selected candidate is chosen only because it solves a similar class of problem while failing the project's explicit constraints
-- [ ] Testing strategy covers AC: Tests map to acceptance criteria
-- [ ] Tech stack documented (if Phase 3 ran): `tech_stack.md` has evaluation tables, risk assessment, and learning requirements
-- [ ] Security analysis documented (if Phase 4 ran): `security_analysis.md` has threat model and per-component controls
-
-## Mode B Specific
-
-- [ ] Findings table complete: All identified weak points documented with solutions
-- [ ] Weak point categories covered: Functional, security, and performance assessed
-- [ ] New draft is self-contained: Written as if from scratch, no "updated" markers
-- [ ] Performance column included: Mode B comparison tables include performance characteristics
-- [ ] Previous draft issues addressed: Every finding in the table is resolved in the new draft
-- [ ] Existing selected components were challenged against a broad alternative landscape before being kept
-- [ ] Existing component fit audited: every old and new component/tool/pattern was checked against `restrictions.md`, `acceptance_criteria.md`, and the Project Constraint Matrix
-- [ ] Rejected/experimental candidates are not lead recommendations unless the user explicitly accepted the risk
-
-## Timeliness Check (High-Sensitivity Domain BLOCKING)
-
-When the research topic has Critical or High sensitivity level:
-
-- [ ] Timeliness sensitivity assessment completed: `00_question_decomposition.md` contains a timeliness assessment section
-- [ ] Source timeliness annotated: Every source has publication date, timeliness status, version info
-- [ ] No outdated sources used as factual evidence (Critical: within 6 months; High: within 1 year)
-- [ ] Version numbers explicitly annotated for all technical products/APIs/SDKs
-- [ ] Official sources prioritized: Core conclusions have support from official documentation/blogs
-- [ ] Cross-validation completed: Key technical information confirmed from at least 2 independent sources
-- [ ] Download page directly verified: Platform support info comes from real-time extraction of official download pages
-- [ ] Protocol/feature names searched: Searched for product-supported protocol names (MCP, ACP, etc.)
-- [ ] GitHub Issues mined: Reviewed product's GitHub Issues popular discussions
-- [ ] Community hotspots identified: Identified and recorded feature points users care most about
-
-## Target Audience Consistency Check (BLOCKING)
-
-- [ ] Research boundary clearly defined: `00_question_decomposition.md` has clear population/geography/timeframe/level boundaries
-- [ ] Every source has target audience annotated in `01_source_registry.md` (or category files under `01_source_registry/` if split)
-- [ ] Mismatched sources properly handled (excluded, annotated, or marked reference-only)
-- [ ] No audience confusion in fact cards: Every fact has target audience consistent with research boundary
-- [ ] No audience confusion in the report: Policies/research/data cited have consistent target audiences
-
-## Source Verifiability
-
-- [ ] All cited links are publicly accessible (annotate `[login required]` if not)
-- [ ] Citations include exact section/page/timestamp for long documents
-- [ ] Cited facts have corresponding statements in the original text (no over-interpretation)
-- [ ] Source publication/update dates annotated; technical docs include version numbers
-- [ ] Unverifiable information annotated `[limited source]` and not sole support for core conclusions
-
-## Exact-Fit Validation (BLOCKING)
-
-- [ ] Project Constraint Matrix extracted from problem context before component selection
-- [ ] Component fit matrix includes `Component Area`, `Option Family`, and `Pinned Mode/Config` columns
-- [ ] Every selected component/tool/library/service/pattern/algorithm has evidence for required inputs/outputs and integration boundaries
-- [ ] Every selected candidate has evidence for the operating context and lifecycle assumptions it must support
-- [ ] Every selected candidate has evidence for non-functional targets that are binding for the project
-- [ ] Known unsupported scenarios and failure reports were searched for every selected candidate
-- [ ] Mismatches are recorded as disqualifiers, not softened into generic limitations
-- [ ] Any candidate with unproven fit is marked `Experimental only` or escalated for user decision
-- [ ] Any candidate with documented constraint conflict is marked `Rejected`
-
-## API Capability Verification (BLOCKING)
-
-**Applicability**: this checklist applies only when the run is classified as **Technical-component selection** (see SKILL.md → Research Output Class). For non-technical research (concept comparison, market/policy investigation, root-cause analysis, knowledge organization), skip this checklist entirely and note the skip in `05_validation_log.md`. For mixed runs, apply only to technical component areas.
-
-For every lead candidate that is a library/SDK/framework/service:
-
-- [ ] The exact mode/configuration the project will use is pinned in one explicit sentence (inputs, outputs, runtime); no vague "supports X" language
-- [ ] `context7` (or equivalent docs lookup) was run for the candidate, with at least 3 queries: mode enumeration, project's exact mode, disqualifier probe
-- [ ] All consulted URLs from context7 / official docs are appended to `01_source_registry.md` (or files under `01_source_registry/` if split)
-- [ ] A Minimum Viable Example (MVE) was saved for the pinned mode in `02_fact_cards.md` / `02_fact_cards/` (or `02_mve_evidence.md`) with: source, inputs in example, outputs in example, project inputs, project outputs required, match assessment ✅/⚠️/❌
-- [ ] When the MVE inputs or outputs do not exactly match the project's, the mismatch is cited from the official docs (not inferred), and the candidate is `Experimental only` or `Rejected`
-- [ ] When a library has multiple modes, each project-relevant mode appears as its own candidate row (not a single library row that softens across modes)
-- [ ] Restrictions × Candidate-Modes sub-matrix in `06_component_fit_matrix.md` (or files under `06_component_fit_matrix/` if split) is filled for every lead candidate, with one row per numbered restriction and per numbered acceptance criterion
-- [ ] Sub-matrix uses ✅ / ❌ / ❓ / N/A only — no free-form prose substitutes
-- [ ] No `Selected` candidate has any ❌ or ❓ cell in its sub-matrix
-- [ ] "Validation gate required" footnotes are explicitly classified as either *API capability* (must be resolved here) or *runtime quality* (may be carried forward)
-- [ ] Paraphrased capability claims in fact cards have been cross-checked against the literal mode-enumeration evidence (no `mono, inertial → mono-inertial` style conflation)