Enhanced the SKILL.md file to enforce conciseness rules for the state file, specifying acceptable content and file size limits. Updated the autodev state to reflect the transition to the planning phase, including changes to the current step and sub-step details. Revised acceptance criteria to clarify validation requirements and external dependencies, ensuring alignment with the latest research findings. Added a new overlay for Mode B revisions to track changes and decisions made during the assessment process.
Updated various documentation files to clarify the handling of splittable artifacts, allowing for folder equivalents of key markdown files when they exceed size limits. Adjusted references in multiple sections to reflect this new structure, ensuring consistency across the research methodology. Enhanced clarity on the saving actions and artifact organization, particularly for `01_source_registry.md`, `02_fact_cards.md`, and `06_component_fit_matrix.md`. This change aims to improve usability and maintainability of the research documentation.
Revised the autodev state to reflect the transition to phase 12, detailing the candidate enumeration for C1 (VIO) with a focus on context7 capability verification and restrictions assessment. Updated the source registry to indicate progress on C1 candidates, including the addition of new sources and their evaluation status. Enhanced fact cards with detailed assessments of VINS-Mono and VINS-Fusion, highlighting their suitability and licensing considerations for dual-use deployment. Deferred context7 verification and structured sub-matrix tasks to the next session.
Updated the meta-rule document to emphasize strict adherence to skill instructions, prohibiting unnecessary investigations or external checks. Revised acceptance criteria and restrictions to correct communication protocol details for ArduPilot and iNav, ensuring clarity on external-positioning interfaces. Adjusted autodev state to reflect ongoing research phase and updated sub-step details for improved tracking.
acceptance_criteria.md and restrictions.md were carrying internal
component selections (DINOv2/SuperPoint/FAISS/ESKF), library pins
(pymavlink/MAVSDK), autopilot parameter values (GPS1_TYPE=14,
EK3_SRC1_*, VISO_QUAL_MIN), and v1/v1.1 phasing tied to specific
ArduPilot PR numbers. Per IEEE 830 / Atlassian / GitScrum,
acceptance criteria must be design-independent — outcomes only,
not implementation. Cleaned both files (-35% combined size) while
preserving every testable threshold and contract bullet.
Output-schema label renamed: vo_extrapolated -> visual_propagated.
FC scope broadened from ArduPilot-only to ArduPilot + iNav (both
via standard MAVLink external-positioning interfaces).
Encoded the lesson into the two skills that write/refine AC:
- problem/SKILL.md (initial AC production)
- research/steps/01_mode-a-initial-research.md (Phase 1 AC
& Restrictions Assessment)
Autodev state reset to greenfield Step 2 (Research) for the
post-restart greenfield run; cycle 1, in-progress at sub-step
ac-restrictions-assessment.
Co-authored-by: Cursor <cursoragent@cursor.com>
- Changed the autodev state to reflect the new phase and task name for remediation related to AZ-243.
- Updated the dependencies table to include the new task AZ-243 and adjusted dependencies for AZ-233.
- Added a section in the implementation completeness report to document the creation of the AZ-243 remediation task aimed at integrating the production native VIO runtime.
- Modified the Docker Compose configuration to include an input root for replay tests and added an environment variable for enabling SITL.
- Enhanced documentation for various testing processes, including the addition of a Runtime Completeness Decomposition Gate and clarifications on internal module testing requirements.
- Updated the implementation completeness report to reflect the current state and added new test cases for performance and resilience scenarios.
Co-authored-by: Cursor <cursoragent@cursor.com>
Confirm the existing blackbox test task set is ready after product
remediation and advance autodev to test implementation.
Co-authored-by: Cursor <cursoragent@cursor.com>
Record that the remediated runtime remains directly testable and
advance autodev to test decomposition.
Co-authored-by: Cursor <cursoragent@cursor.com>
- Refined task decomposition steps to ensure implementation tasks are atomic and complexity does not exceed 5 points.
- Enhanced the product implementation process with a completeness gate to verify task outcomes against architecture promises before proceeding to testing.
- Updated dependencies table to reflect new tasks and their relationships, ensuring all test tasks are linked to product remediation tasks.
- Adjusted workflow documentation to clarify entry points for task decomposition and implementation contexts.
Co-authored-by: Cursor <cursoragent@cursor.com>
Keep generated tiles auditable and untrusted onboard while preserving
covariance, quality, and sidecar metadata for post-flight sync.
Co-authored-by: Cursor <cursoragent@cursor.com>
Implement the first runtime component boundaries around the shared
contracts so downstream batches can consume typed frame, MAVLink, tile,
and FDR behavior with focused tests and batch evidence.
Co-authored-by: Cursor <cursoragent@cursor.com>
Provide deterministic geometry/time-sync helpers and structured config, error, health, and telemetry primitives for downstream runtime components.
Co-authored-by: Cursor <cursoragent@cursor.com>
Implement the shared DTO contract surface with validation so runtime components consume one public model set instead of duplicating shapes.
Co-authored-by: Cursor <cursoragent@cursor.com>
Keep VIO package and native bridge paths backend-neutral so BASALT remains an implementation choice rather than a component boundary.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add the initial source, test, infrastructure, CI, configuration, and evidence-path scaffold so dependent implementation tasks have stable package and runtime boundaries.
Co-authored-by: Cursor <cursoragent@cursor.com>
- Revised acceptance criteria in the acceptance_criteria.md file to clarify metrics and expectations, including updates to GPS accuracy and image processing quality.
- Enhanced restrictions documentation to reflect operational parameters and constraints for UAV flights, including camera specifications and satellite imagery usage.
- Added new research documents for acceptance criteria assessment and question decomposition to support ongoing project evaluation and decision-making.
Oleksandr Bezdieniezhnykh