From a design to experience
The course-cancellation example explains a fictional design. Related open-source projects offer separate implementation records to examine. Use their code, checks and documented limitations to investigate a specific architectural question.
Rules and execution
The CREXX toolchain compiles cREXX source, assembles and links bytecode, and runs it in a virtual machine. It provides a practical setting for examining language rules, component contracts, packaging and compatibility. The repository distinguishes released baselines from work in progress.
A useful review follows one rule change through its inputs, implementation, checks and release. Ask what callers can rely on and which change would require them to act. Connect that review to the Systems guidance.
Information and recovery
The cREXX-RAG repository describes a local operational baseline for document retrieval and a typed knowledge graph. It retains sources, claims, uncertainty and work history in a cREXX application. Its qualification record keeps local results separate from wider platform and long-running checks.
Its recovery journey describes inspection, reconciliation, retry and reasoned waivers while retaining original outcomes. Use it to examine how a system distinguishes unfinished work from successful work, and what an operator needs before retrying an uncertain action. These questions connect to Information and deployment and operations.
Editors and interfaces
DSLSH keeps an editor and parser synchronised. THE CREXX Edition provides an editor integration and an experimental browser interface. Their repositories describe the responsibilities, interactions and limits.
Examine what happens when the editor changes before a parser response arrives, and which component owns the accepted document state. Use the integration guidance to record the contract and the checks needed when either participant changes.
Record the lesson
Choose one dated implementation change. Retain its question, alternatives, decision, changed code or configuration, checks, observed results and remaining limits. Distinguish the project’s observation from a hypothesis about why it happened. Compare the result with the assessment questions.
Use the decision and change record to retain the lesson. Record whether it changes a local implementation, a shared design or the guidance itself. The project map gives each related project’s role and authoritative home.
Earlier proposal
An earlier Portal example proposed an appointment-rebooking demonstration, with an authoritative appointment record, repeatable work request, deadline rule and recovery. It remains a separate proposal in the site’s history. The worked example develops the course-cancellation service used throughout the current framework and blueprint.