Plan formal-verification Makefile targets (15.1.4)

[lodyai]

Summary

Draft execution plan for roadmap item 15.1.4 (formal verification →
verification workspace and tooling), adding the test-verification, kani,
kani-full, verus, formal-pr, and formal-nightly Makefile targets.

The plan document is
docs/execplans/15-1-4-formal-verification-makefile-targets.md.

This PR contains the execplan only — implementation has not started and awaits
approval of the plan.

Key design decision

Three of the six targets (kani, kani-full, verus) have no harnesses or
proofs to run yet — those land in later roadmap items (15.3.x and 15.5.x) — yet
the success criterion requires each target to return exit 0 on a clean tree.

After a Logisphere community-of-experts design review, the plan adopts explicit
stubs over self-activating skip guards:

• test-verification runs the existing Stateright model tests for real today.
• kani, kani-full, and verus invoke a shared scripts/formal-stub.sh that
  prints a structured FORMAL-SKIP: marker and exits 0, or exits non-zero
  under FORMAL_STRICT=1.
• The roadmap item that owns each harness/proof replaces the stub recipe in a
  loud, reviewable edit; FORMAL_STRICT gives 15.1.5 (CI) a tripwire against a
  forgotten activation.

The review also corrected the test strategy: the existing formal-tooling helpers
cannot assert prerequisite-only aggregate rules or a wrapped .PHONY, so the
plan adds a target_prerequisites helper and hardens has_phony_target.

Planning method

• Studied the roadmap, docs/formal-verification-methods-in-wireframe.md, and
  the existing tests/formal_tooling.rs harness.
• Used Firecrawl to review prior-art Makefiles in leynos/netsuke,
  leynos/chutoro, and leynos/mxd.
• Ran a planning agent team to map the verification crate and documentation
  surfaces, then a Logisphere design-review panel (Pandalump, Telefono,
  Wafflecat, Dinolump, Doggylump) to stress-test and revise the design.

Reviewer focus

• Is the explicit-stub design (with FORMAL_STRICT) the right call versus
  landing a minimal real harness/proof now?
• Is the aggregate composition (formal-pr: test-verification kani verus)
  acceptable given check-kani-version is excluded to keep the clean-tree gate
  tool-free?
• Are the six target names and semantics aligned with the formal-verification
  methods document?

References

• Lody session: https://lody.ai/leynos/sessions/b2c19e9f-b094-4f34-adf8-d4ec1549fdd3

[sourcery-ai]

Sorry @LodyAI[bot], you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: c9f836f5-40f7-45be-aee6-cf952d43e039

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 15-1-4-formal-verification-makefile-targets

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}