Skip to content

Readme.md

Latest commit

 

History

History
461 lines (350 loc) · 12.8 KB

Readme.md

File metadata and controls

461 lines (350 loc) · 12.8 KB

FROG logo

Executable Conformance — Invalid Cases

Negative execution-ready cases for bounded published FROG execution corridors
FROG — Free Open Graphical Language

Contents

1. Overview

This directory defines negative executable conformance cases for bounded published FROG execution corridors.

A case in this family does not merely state that a program is rejected somewhere upstream in the compiler corridor. It states that a case that may already be:

  • loadable,
  • structurally valid,
  • semantically accepted,
  • IR-derivable,
  • lowerable,
  • backend-contract-emittable,
  • backend-family consumable,

still fails to qualify as valid executable public truth under the bounded published execution corridor.

This family therefore exists to make execution-side rejection public, explicit, and testable.

2. Why This Family Exists

The repository-wide architecture already distinguishes: 

backend-family consumability
   !=
execution-start readiness

That means a case may have passed the compiler-oriented corridor and still fail later because:

  • execution-contract assumptions are not satisfied,
  • required host-service assumptions are not explicit or not available,
  • the execution unit is ambiguous,
  • the selected execution mode is unsupported or inconsistent,
  • startup fails under conditions that the bounded corridor does not allow to be treated as success.

This family exists so that those failures become public truth rather than implementation folklore.

3. Architectural Position

This family must be read under the repository-wide layering: 

Expression/
   - canonical source

Language/
   - validated meaning

IR/
   - canonical execution-facing representation
   - lowering
   - backend contract

Profiles/
   - optional bounded compilation corridors
   - optional bounded execution contracts

Conformance/
   - public accept / reject / preserve truth surface

Accordingly:

  • this family does not redefine source law,
  • this family does not redefine semantic law,
  • this family does not redefine canonical IR,
  • this family does not redefine backend contract ownership,
  • this family only exposes negative public truth for execution-side failure or rejection once the upstream corridor has gone far enough for that distinction to matter.

4. Scope

This family defines negative executable conformance cases for bounded corridors where the repository publishes enough upstream material to justify execution-side rejection as a distinct public outcome.

An invalid executable case in this family is intended to show that:

  • the upstream compiler corridor may already have succeeded far enough,
  • but the relevant execution-contract assumptions are not satisfied where such a contract exists,
  • or execution start fails under explicitly in-scope published conditions,
  • or observable executable truth cannot be claimed without violating the bounded corridor.

This family is therefore narrower than general invalidity.

5. Non-Goals

This family is not:

  • a catch-all folder for all rejected programs,
  • a replacement for invalid/compiler/,
  • a private runtime failure log,
  • a place where unpublished implementation instability becomes normative truth,
  • a proof that the language is invalid merely because one bounded execution corridor rejects a case.

A case belongs here only when executable rejection is the correct architectural stage of rejection.

6. Reading Model

The intended reading model for a negative executable case is: 

source may be accepted
   ->
meaning may be accepted
   ->
IR may be preserved
   ->
lowering may be accepted
   ->
backend contract may be accepted
   ->
execution-contract assumptions fail
      or
   execution-start fails under published bounded conditions
   ->
public executable truth is rejection or failure, not success

This family therefore depends on the compiler corridor, but it adds a distinct execution-side rejection surface.

7. Family Entry Condition

A case belongs in this family only if all of the following are true:

  • the relevant source and semantic rules are already published,
  • the relevant IR, lowering, and backend-contract rules are already published,
  • the relevant profile corridor is already published where the case depends on one,
  • the relevant execution contract is already published where execution-side rejection depends on one,
  • the rejection or failure can be stated as public truth without relying on hidden private assumptions.

If those conditions are not met, the case should remain draft-only or stay in a compiler-corridor family instead.

8. Expected Negative Truth

A negative executable case in this family is expected to make one of the following public claims:

  • the case is backend-consumable but not execution-contract-valid,
  • the case is execution-contract-invalid before start,
  • the case is permitted to try starting but startup fault occurs under a published in-scope condition,
  • the case cannot claim valid executable truth because its execution-side obligations are not satisfied.

Each case MUST make clear whether it is testing:

  • pre-start rejection,
  • startup fault,
  • unsupported execution mode,
  • unsupported host-service dependency,
  • another explicitly published execution-side negative condition.

9. Required Case Material

A fully published negative executable case in this family SHOULD include enough companion material to make its rejection stage clear and checkable.

Depending on the case, that may include:

  • the canonical source file,
  • the expected canonical IR form where relevant,
  • the expected lowered form where relevant,
  • the expected backend contract where relevant,
  • the execution mode being claimed or denied,
  • the execution-unit assumptions,
  • the expected rejection stage or expected startup-fault condition,
  • machine-checkable metadata or manifests where the published conformance format later standardizes them.

10. Minimal Negative Case Shapes

The first cases in this family should remain conservative and sharply staged.

The most natural first negative executable shapes are:

  • backend-contract-valid but execution-contract-invalid,
  • execution-contract-valid in appearance but missing a required declared host service,
  • execution mode mismatch against the bounded published corridor,
  • startup fault under an explicitly published in-scope condition.

The least suitable first anchors are:

  • large UI-runtime failure cases,
  • vendor-specific packaging failures,
  • private runtime bugs with no published normative meaning,
  • target-fragmented failures that depend on unpublished backend internals.

11. Relation with Compiler Conformance

This family does not replace invalid/compiler/.

Instead, it extends the staged corridor beyond compiler-side rejection.

The intended relation is: 

invalid/compiler/
   proves
rejection before executable truth is even in scope

invalid/executable/
   proves
the case passed far enough that executable truth is now the correct rejection surface

Accordingly: 

backend-family consumable
   does not imply
valid/executable/ membership

and may still imply
invalid/executable/ membership

12. Relation with Profiles and Execution Contracts

Where a negative executable case depends on a bounded optional profile corridor, it must be read relative to that profile.

Where execution-side rejection depends on a published profile-level execution contract, the case must also be read relative to that contract.

The intended distinction is: 

profile
   defines
bounded capability corridor

backend contract
   defines
generic standardized downstream handoff

execution contract
   defines
bounded execution-start closure

invalid/executable/
   tests
negative public truth
after the corridor has advanced far enough
for execution-side rejection to matter

13. Case Naming and Ordering

Cases in this family SHOULD be numbered conservatively and named by the public negative truth they expose.

Good names are names such as:

  • 01_backend_consumable_but_execution_contract_invalid,
  • 02_execution_contract_valid_but_required_host_service_missing,
  • 03_one_shot_startup_faults_under_published_condition.

Poor names are names tied only to vendor internals, incidental crash signatures, or private runtime implementation details.

14. First Family Anchor

The first coherent anchor for this family is a case that is:

  • backend-contract-valid,
  • clearly still outside valid execution-start truth,
  • rejected for one bounded, published, execution-side reason.

That makes the smallest sharp first anchor: 

backend consumable
   but
execution-contract invalid

This is the right first mirror of the positive executable family because it isolates the missing execution-side closure without introducing large runtime-private ambiguity.

15. Future Growth

Future growth in this family should remain corridor-first and conservative.

A good growth order is:

  1. backend-consumable but execution-contract-invalid,
  2. execution-mode mismatch,
  3. required declared host-service missing,
  4. published startup-fault conditions,
  5. richer runtime-side rejections only after the corresponding published execution corridor exists.

This family should therefore grow by closing one negative executable truth surface at a time rather than by collecting arbitrary runtime failures.

16. Summary

This directory defines negative executable conformance cases for bounded published FROG execution corridors.

A case in this family proves more than compiler-side rejection. It proves that, under a published bounded corridor: 

execution truth is not valid
even though the case may already have advanced far into the compiler corridor

That is the intended role of Conformance/invalid/executable/ in the future growth of the FROG public truth surface.