# Mission Readiness engineering notes

This is an AI-assisted interactive portfolio work sample for Mahosha Sandaru Kaballamuru, an aerospace engineering graduate and Aerospace/Mechanical Quality Inspector. It connects an illustrative spacecraft configuration task with inspection evidence and verification planning. The degree, employment and academic project context are documented in the linked portfolio PDF. The game is a new educational artifact, not a completed spacecraft project or flight software.

## Model and decisions

The fictional brief has a 12 kg total allowance with a fixed 1.2 kg reserve, so equipment mass must not exceed 10.8 kg. Every selected component contributes mass. Only the fixed bus, payload, radio and optional adapter contribute load. Continuous and simultaneous peak allocations are checked independently against the selected power module. Payload data rate is compared with radio capacity. CAN payloads connect directly; the RS422 payload needs a correctly directed RS422-to-CAN adapter.

An imaging study and a composition study are both permitted in this brief. They require different supporting hardware. The standard frame has a fictional vibration record in the scenario; a new lightweight frame requires additional verification planning. These are exercise assumptions, not real hardware specifications or a general space qualification policy.

Inspection uses a fixed scenario date of 24 October 2026. A measurement inside a tolerance is not accepted if the instrument's calibration has expired. A valid out-of-limit alignment measurement follows the stated authorised rework route and requires re-inspection. Selecting a disposition or test does not perform the work. The final record therefore retains a hardware HOLD for outstanding evidence, even when the exercise score reaches 100.

## Acceptance tests and implementation provenance

The independently supplied suite now contains 33 tests. All 33 passed against the final integration candidate in an isolated node:24-alpine Docker container with network disabled, a read-only filesystem and an unprivileged user. Tests cover two feasible configurations, independent mass/power/data limits, exact boundaries, adapter direction, invalid input, real calendar dates, calibration expiry, disposition precedence, signed measurements, plan deduplication and configuration-dependent coverage. This result covers the supplied cases; it is not universal correctness or hardware validation.

The local-first generation bridge was used. Its first job stopped when the sandbox became unavailable during the second attempt. After runtime readiness was rechecked, the restarted job exhausted two local attempts and one permitted GPT-4o fallback. The fallback still failed tests. Codex corrected the final integration defects and reran the independent suite; no additional paid retry was made. The original requests, provider streams, candidates, validator logs and verdicts remain in the original bridge job directories. Those failed job states have not been relabelled as verified. The final engine checksum and test scope are available in test-report.json; engine-tests.cjs contains the supplied tests.

The browser interface, original spacecraft SVG, interaction design and integration were developed with AI assistance. Real portfolio project evidence is separated from fictional game data. A player's optional rationale is not automatically graded. The exercise score is not an assessment of hiring suitability.

## Scoring and browser behavior

Configuration: five independent checks worth 8 points each, for 40 total. Inspection: three correct dispositions worth 10 each, for 30 total. Verification: the fraction of active required checks covered, worth up to 30 points, minus 5 for each selected item outside this exercise's required scope. Revising choices is allowed and there is no speed bonus. A reference solution is explicitly labelled as a walkthrough.

Review state stays in the current browser tab. No analytics, accounts or server-side scoring are implemented. A JSON decision record is created locally only when the player chooses to download it. The portable version needs no build step or network access for gameplay. The PDF and any external links are separate resources.