Full-code Development
Reference: This page is a source-based technical synthesis of the LaTeX chapter cited below. For exact syntax, availability or ABI signatures, verify the versioned source, manifest and executable tests.
Scope and source boundary
Full-code extensions operate within registered runtime contracts and should preserve declared semantic meaning.
Full-code extensions must use the Runtime contract for the responsibility being added rather than creating a parallel engine. The source chapter documents dedicated extension points for graph transforms, operationalization ranking, candidate validation, transactions, execution engines and services. Each extension is defined by an ownership model, symmetric registration/teardown and executable tests.
Engineering rules
- Choose the extension contract first:
HypergraphTransform, a ranking provider, a validator, an engine orIServiceInstanceaccording to the need. - A ranking provider reorders symbolically valid candidates; it may not turn invalid candidates into valid ones.
- Include positive, negative, idempotence and ownership/cleanup cases in the test suite.
- Register and unregister the extension symmetrically, and preserve a deterministic fallback where scoring data are unavailable.
Chapter outline (original LaTeX headings)
- Choose the Extension Contract Before Writing Code
- Recipe 1: Add a Hypergraph Transform
- Mandatory tests for a transform
- Recipe 2: Add a Ranking Provider Without Weakening the Hard Gate
- Mandatory tests for a ranking provider
- Recipe 3: Add a Learned Score Provider
LaTeX provenance
Primary chapter: Runtime/logiCells Runtime Programming with RadStudio/full-code-runtime-extension-recipes.tex.