nasa-power-of-ten

name

nasa-power-of-ten

description

Write, refactor, and audit high-reliability code using Gerard J. Holzmann's NASA/JPL Power of Ten rules. Use for safety-critical or mission-critical code, embedded and real-time C/C++, bounded execution and memory reviews, strict static-analysis readiness, or requests mentioning NASA rules, JPL rules, Power of Ten, Power of 10, reliable code, zero warnings, recursion bans, loop bounds, assertion density, or post-initialization allocation. Apply an explicitly labeled intent-preserving adaptation for non-C languages; do not claim literal Power of Ten compliance for an adaptation.

NASA Power of Ten

Apply the ten rules as an analyzability discipline. Produce evidence, not reassurance. Treat the original rules as C-oriented constraints—not as NASA certification, a complete safety standard, or a substitute for hazard analysis, requirements traceability, testing, qualified tools, MISRA/CERT guidance, or project-specific standards.

Select the profile

Choose before editing or reviewing:

• Strict: Use for C, safety-critical claims, exact NASA/JPL requests, or when the user does not authorize deviations. Apply the original rule semantics. Mark every uncertain rule UNVERIFIED; do not silently relax it.
• Adapted: Use for Rust, Ada/SPARK, C++, Go, Java, C#, Python, JavaScript, or another language whose semantics do not map literally. Preserve boundedness, predictable resources, local reasoning, defensive contracts, restricted indirection/metaprogramming, and tool-clean builds. Label the result Power-of-Ten-inspired; never call it strict compliance.

If the requested profile is unclear, infer Strict for C and Adapted otherwise. State the inference in the result. Read references/language-adaptations.md before applying the adapted profile.

Use the rules

Use these IDs consistently in code comments and reports:

ID	Enforce
P10-1	Use simple control flow; prohibit goto, setjmp/longjmp, and direct or indirect recursion.
P10-2	Give every terminating loop a statically provable upper bound; prove intentional nonterminating loops cannot terminate.
P10-3	Perform no dynamic memory allocation after initialization.
P10-4	Keep each function to roughly one printed page, normally at most 60 source lines under the original counting convention.
P10-5	Average at least two meaningful, side-effect-free assertions per function and define explicit recovery for failures.
P10-6	Declare each data object at the smallest possible scope.
P10-7	Check every non-void return value and validate every function's parameters; make intentional discards explicit and justified.
P10-8	Limit preprocessing to header inclusion and simple, complete-unit macros; prohibit token pasting, variadics, and recursive macros; minimize and justify conditional compilation.
P10-9	Limit pointers to one dereference level; do not hide dereferences in macros or typedefs; prohibit function pointers.
P10-10	Enable the compiler's strictest practical warning set from day one and reach zero warnings; run one or preferably multiple static analyzers regularly and reach zero unresolved diagnostics.

Read references/power-of-ten.md whenever a rule's exact boundary, rationale, exception, or required evidence affects a decision.

Execute the workflow

1. Establish scope. Identify the language, target, lifecycle, initialization boundary, entry points, generated or third-party code, build commands, configured analyzers, and repository instructions. Do not audit code outside the user's scope.
2. Build an evidence map. Map each rule to source inspection, compiler output, analyzer output, tests, formal proof, or an explicit manual review. Existing green tests are not evidence for all ten rules.
3. Run mechanical triage. For C/C++, run python3 <skill-dir>/scripts/p10_scan.py <paths> when Python 3 is available. Use --format json for machine-readable output. Treat every result as a lead; this scanner cannot prove compliance.
4. Inspect rule by rule. Trace the call graph for recursion and indirect calls; prove loop bounds; identify the initialization phase; measure functions; assess assertion quality and recovery; inspect scopes and all call sites; expand macros and conditional variants; trace pointer depth; inspect the actual warning and analyzer configuration.
5. Change conservatively. Preserve behavior and interfaces unless the user asks otherwise. Prefer small functions, explicit state machines, counted loops, fixed-capacity storage, narrow scopes, checked result types, pure contracts, direct calls, and transparent code.
6. Verify proportionally. Run the repository's formatter, tests, strict compiler build, and configured analyzers. Do not install tools, alter global settings, or broaden the task without authorization. Record commands and exact outcomes.
7. Report residual uncertainty. Never convert “not detected,” “tests pass,” or “scanner clean” into PASS without adequate evidence.

Read references/verification-playbook.md when configuring evidence collection, evaluating P10-10, or conducting a formal audit.

Apply exceptions without weakening the standard

Do not invent blanket exceptions. When a rule cannot be met:

1. Mark it WAIVED, not PASS.
2. Record the exact symbol and source location.
3. State why compliance is infeasible and which hazard the rule controls.
4. Add compensating controls and verification evidence.
5. Name the owner or approval authority if the project defines one.
6. Keep the waiver narrow and reviewable.

For strict audits, any FAIL, UNVERIFIED, or unapproved WAIVED item prevents an overall compliant result.

Produce the result

Lead with the profile and overall result. Use only these statuses: PASS, FAIL, UNVERIFIED, NOT_APPLICABLE, WAIVED.

For a review, provide:

1. Outcome — profile, scope, and whether compliance was established.
2. Findings — ordered by safety impact, each with rule ID, status, file and line, concrete evidence, consequence, and smallest credible fix.
3. Rule matrix — exactly one row for P10-1 through P10-10, including evidence or the missing proof.
4. Verification — commands and outcomes; distinguish configured tools from tools merely suggested.
5. Waivers and residual risk — narrow deviations, compensating controls, and unresolved uncertainty.

Use references/report-template.md when the user requests a formal audit artifact. For implementation work, summarize the rules affected and verification performed instead of emitting an empty audit template.

Guardrails

• Do not claim NASA, JPL, regulatory, certification, flight, medical, automotive, or functional-safety approval.
• Do not describe the heuristic scanner as a linter, analyzer, proof engine, or certification tool.
• Do not add meaningless assertions, arbitrary loop caps, ignored-result casts, or comments solely to silence checks.
• Do not disable diagnostics or weaken warning levels to achieve zero warnings.
• Do not rewrite third-party or generated code merely to make the project look compliant; isolate it and report its boundary.
• Do not treat safe-language abstractions as automatically compliant. Hidden allocation, unbounded iteration, dynamic dispatch, panics/exceptions, and runtime metaprogramming still require analysis.