Refactor documentation to replace the Validation Harness with a separate E2E Test Suite, updating references throughout various documents. Adjust the autodev state to reflect the transition from the Decompose phase to the Implement phase, and revise the architecture documentation to clarify system boundaries and component relationships. Enhance risk mitigation documentation to specify affected components and update the component overview diagram accordingly.

This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-05-03 11:50:39 +03:00
parent 5bf2dbd85f
commit dd9afe2797
31 changed files with 1479 additions and 396 deletions
@@ -0,0 +1,87 @@
# Satellite Service Sync Boundary
**Task**: AZ-229_satellite_service_sync
**Name**: Satellite Service Sync Boundary
**Description**: Import mission cache packages before flight and upload generated-tile packages after flight.
**Complexity**: 3 points
**Dependencies**: AZ-222_runtime_config_errors_telemetry, AZ-225_tile_manager_cache_manifest, AZ-226_generated_tile_orthorectification
**Component**: Satellite Service
**Tracker**: AZ-229
**Epic**: AZ-214
## Problem
The onboard runtime needs a clear boundary for Satellite Service package exchange without allowing mid-flight network calls.
## Outcome
- Pre-flight cache packages can be imported and handed to Tile Manager validation.
- Post-flight generated-tile packages can be uploaded/retried.
- Mid-flight provider or Satellite Service calls are explicitly blocked.
## Scope
### Included
- Pre-flight import behavior.
- Post-flight generated-tile upload behavior.
- Package status and retry/error reporting.
### Excluded
- In-flight retrieval ranking.
- Tile manifest validation and generated tile creation.
## Dependencies
### Document Dependencies
- `_docs/02_document/contracts/shared/runtime_contracts.md`
- `_docs/02_document/contracts/shared/config_errors_telemetry.md`
## Acceptance Criteria
**AC-1: Pre-flight package import succeeds**
Given a valid Satellite Service mission cache package
When import runs before flight
Then the package is available for Tile Manager validation.
**AC-2: Post-flight upload is auditable**
Given a generated-tile package exists after landing
When upload runs
Then success, rejection, or retryable failure is recorded.
**AC-3: Mid-flight network calls are blocked**
Given the runtime is in flight mode
When cache data is missing
Then the component does not call a satellite provider or suite service.
## Non-Functional Requirements
**Reliability**
- Upload failures retain packages for retry.
**Security**
- Signing credentials are never logged.
## Unit Tests
| AC Ref | What to Test | Required Outcome |
|--------|--------------|------------------|
| AC-1 | Valid import package | Package ready for validation |
| AC-2 | Upload unavailable | Retryable failure recorded |
| AC-3 | Flight-mode missing data | No network call |
## Blackbox Tests
| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
|--------|-------------------------|--------------|-------------------|----------------|
| AC-3 | Network disabled in replay | Relocalization missing data | Degraded/no-candidate behavior, no fetch | Security |
## Constraints
- No in-flight Satellite Service or satellite-provider network dependency.
- Package sync is before takeoff or after landing only.
## Risks & Mitigation
**Risk 1: Boundary confusion**
- *Risk*: Retrieval code starts fetching provider data mid-flight.
- *Mitigation*: Flight-mode invariant is acceptance-tested.