azaion/gps-denied-onboard
1
0
Fork 0
mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-22 21:31:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

update reserach skill

Browse Source
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-04-29 11:58:37 +03:00
parent f321268e1b
commit 5391d2c710
16 changed files with 1263 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.cursor/skills/research/steps/04_engine-analysis.md
+36
View File
@@ -24,6 +24,15 @@ Write to `03_comparison_framework.md`:
| ... | | | |
```
**Required exact-fit dimensions for component/tool decisions**:
When the output selects or recommends a component, tool, library, service, architecture pattern, or algorithm, the framework MUST include these dimensions unless explicitly not applicable:
- Required inputs/outputs and ownership boundaries
- Operating context and lifecycle fit
- Non-functional envelope fit
- Implementation assumptions and hard disqualifiers
- Evidence quality and source tier
- Selection status (`Selected`, `Rejected`, `Experimental only`, `Needs user decision`)
---
### Step 5: Reference Point Baseline Alignment
@@ -97,6 +106,8 @@ Validate conclusions against a typical scenario:
- [ ] Are there any important dimensions missed?
- [ ] Is there any over-extrapolation?
- [ ] Are conclusions actionable/verifiable?
- [ ] Does every selected component/tool/pattern match the Project Constraint Matrix?
- [ ] Are mismatches marked as disqualifiers instead of hidden as generic "limitations"?
**Save action**:
Write to `05_validation_log.md`:
@@ -128,6 +139,31 @@ If using Y: [expected behavior]
---
### Step 7.5: Component Applicability Gate (BLOCKING)
Before finalizing the solution draft, build an exact-fit matrix for every component/tool/library/service/pattern/algorithm that is selected, recommended, rejected, or treated as a fallback.
```markdown
# Component Fit Matrix
| Candidate | Intended Role | Project Constraints Checked | Evidence | Mismatches / Disqualifiers | Status | Decision Rationale |
|-----------|---------------|-----------------------------|----------|----------------------------|--------|--------------------|
| [name] | [role] | [constraints] | [Fact # / Source #] | [none / list] | Selected / Rejected / Experimental only / Needs user decision | [why] |
```
Rules:
- `Selected` is allowed only when the candidate's documented implementation assumptions match the project's explicit constraints and acceptance criteria.
- `Experimental only` is required when a candidate might work but lacks proof for the exact operating context.
- `Rejected` is required when documented assumptions conflict with project constraints.
- `Needs user decision` is required when a mismatch changes scope, cost, safety, product behavior, or acceptance criteria.
- A candidate may not appear as the lead solution in Step 8 unless this gate marks it `Selected`.
**Save action**: Write `06_component_fit_matrix.md`.
**BLOCKING**: If any lead candidate is `Experimental only`, `Rejected`, or `Needs user decision`, do not silently proceed. Ask the user or choose a different selected candidate.
---
### Step 8: Deliverable Formatting
Make the output **readable, traceable, and actionable**.