Remove UAV frame material documentation and update README with detailed project requirements. Refactor skills documentation to clarify modes of operation and enhance input specifications. Delete unused E2E test infrastructure template.

This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-03-18 16:40:50 +02:00
parent 3ab47526bd
commit d969bec3b6
27 changed files with 2551 additions and 203 deletions
@@ -0,0 +1,78 @@
# E2E Functional Tests Template
Save as `PLANS_DIR/<topic>/e2e_test_infrastructure/functional_tests.md`.
---
```markdown
# E2E Functional Tests
## Positive Scenarios
### FT-P-01: [Scenario Name]
**Summary**: [One sentence: what end-to-end use case this validates]
**Traces to**: AC-[ID], AC-[ID]
**Category**: [which AC category — e.g., Position Accuracy, Image Processing, etc.]
**Preconditions**:
- [System state required before test]
**Input data**: [reference to specific data set or file from test_data.md]
**Steps**:
| Step | Consumer Action | Expected System Response |
|------|----------------|------------------------|
| 1 | [call / send / provide input] | [response / event / output] |
| 2 | [call / send / provide input] | [response / event / output] |
**Expected outcome**: [specific, measurable result]
**Max execution time**: [e.g., 10s]
---
### FT-P-02: [Scenario Name]
(repeat structure)
---
## Negative Scenarios
### FT-N-01: [Scenario Name]
**Summary**: [One sentence: what invalid/edge input this tests]
**Traces to**: AC-[ID] (negative case), RESTRICT-[ID]
**Category**: [which AC/restriction category]
**Preconditions**:
- [System state required before test]
**Input data**: [reference to specific invalid data or edge case]
**Steps**:
| Step | Consumer Action | Expected System Response |
|------|----------------|------------------------|
| 1 | [provide invalid input / trigger edge case] | [error response / graceful degradation / fallback behavior] |
**Expected outcome**: [system rejects gracefully / falls back to X / returns error Y]
**Max execution time**: [e.g., 5s]
---
### FT-N-02: [Scenario Name]
(repeat structure)
```
---
## Guidance Notes
- Functional tests should typically trace to at least one acceptance criterion or restriction. Tests without a trace are allowed but should have a clear justification.
- Positive scenarios validate the system does what it should.
- Negative scenarios validate the system rejects or handles gracefully what it shouldn't accept.
- Expected outcomes must be specific and measurable — not "works correctly" but "returns position within 50m of ground truth."
- Input data references should point to specific entries in test_data.md.