All experiments

Acme Workboard

Model a small workboard once in a root BlockML library, then derive a React companion and an Angular companion from that model.

1. You

   Initialize the Project

   Start with an empty directory and initialize a new BlockML project for the Acme Workboard.

   terminal npx Copy

   npx @blockml/cli init com.acme.workboard
   npm install
   npx blockml validate

   The init command creates a complete minimal Blockmaschine project, including:

   • a package.json
   • the BlockML CLI setup
   • a minimal com.acme.workboard BML library
   • its Library.bml and README

   The generated package.json references the root BML library:

   package.json json Copy

   {
     "blockml": {
       "library": "./blocks/com/acme/workboard/Library.bml"
     }
   }

   After npx blockml validate completes successfully, the initial Blockmaschine project is ready.

   At this point the BML library is still intentionally minimal. It will become the authoritative Workboard SSOT in a later step.

   Next: Convert the project into a monorepo and add the React and Angular companions.

2. Agent

   Convert to a companion monorepo

   Turn the initialized repository into an npm workspace and add empty React and Angular companion applications. Leave the root BlockML library where it is.

   Copy this prompt into a coding agent. Open it to read the full text.

   Agent prompt Copy Show prompt

   # Step 2 — Convert Existing Blockmaschine Project to a Companion Monorepo
   
   The repository has already been initialized as a complete Blockmaschine project using the BlockML initialization command.
   
   Your task in this step is **only to convert the existing repository into a monorepo and add empty React and Angular companion applications**.
   
   Do not create, replace, restructure, or model the root BlockML library.
   
   ## Existing Repository
   
   The repository already contains a complete minimal Blockmaschine project, including:
   
   - the root BlockML library `com.acme.workboard`
   - its `Library` definition
   - its README
   - the BlockML CLI and project configuration
   - the root `package.json`
   - all other files created by the BlockML initialization command
   
   Treat this existing setup as the authoritative starting point.
   
   The existing root BlockML library is already the future authoritative SSOT.
   
   **Preserve it.**
   
   Do not recreate it, move it into another package, replace its configuration, or add Workboard domain content to it in this step.
   
   ## Goal
   
   Turn the existing repository into a simple monorepo that additionally contains two companion applications:
   
   ```text
   Existing Blockmaschine Project
   │
   ├── com.acme.workboard              existing authoritative BML library
   │
   ├── React Companion                 new
   │   └── Derived BML SSOT            placeholder/location only
   │
   └── Angular Companion               new
       └── Derived BML SSOT            placeholder/location only
   ```
   
   The result should provide the infrastructure for the following later steps:
   
   1. The existing repository and Blockmaschine project — already completed
   2. **Monorepo and companion setup — this step**
   3. Model the Workboard domain in `com.acme.workboard`
   4. Agentically derive and render the React companion
   5. Agentically derive and render the Angular companion
   
   Do not perform steps 3–5.
   
   ## Monorepo Setup
   
   Convert the existing root `package.json` to support npm workspaces while preserving all existing BlockML/Blockmaschine configuration, dependencies, scripts, and behavior unless a change is strictly necessary for the monorepo setup.
   
   Prefer plain npm workspaces.
   
   Do not introduce Nx, Turborepo, or another monorepo framework.
   
   Create workspace packages for:
   
   - the React companion
   - the Angular companion
   
   The existing root Blockmaschine project and its BML library should remain where they currently are.
   
   Do not artificially turn the existing BML library into another workspace package merely to make the repository look more symmetrical.
   
   ## React Companion
   
   Create a minimal modern React application using TypeScript.
   
   The companion should:
   
   - be part of the npm workspace
   - build successfully
   - start independently
   - contain only a minimal placeholder UI identifying it as the Workboard React Companion
   
   Do not implement Workboard functionality.
   
   Prepare a clearly identifiable location within the React companion for its future **derived BML SSOT**.
   
   Do not populate that derived SSOT with the Workboard model yet.
   
   ## Angular Companion
   
   Create a minimal modern Angular application using TypeScript.
   
   The companion should:
   
   - be part of the npm workspace
   - build successfully
   - start independently
   - contain only a minimal placeholder UI identifying it as the Workboard Angular Companion
   
   Do not implement Workboard functionality.
   
   Prepare a clearly identifiable location within the Angular companion for its future **derived BML SSOT**.
   
   Do not populate that derived SSOT with the Workboard model yet.
   
   ## SSOT Architecture
   
   The existing root BML library:
   
   `com.acme.workboard`
   
   is the authoritative SSOT.
   
   Later, each companion will contain its own derived BML SSOT:
   
   ```text
   com.acme.workboard
           │
           ├──> React Derived SSOT
           │          │
           │          └──> React Artifact
           │
           └──> Angular Derived SSOT
                      │
                      └──> Angular Artifact
   ```
   
   The derived companion SSOTs are:
   
   - generated from the authoritative root model
   - specific to their respective companion
   - reproducible
   - disposable
   - safe to delete and regenerate
   - not authoritative
   
   In later steps, an agent will both derive these SSOTs and produce the corresponding application artifacts.
   
   No compiler is involved in that rendering process.
   
   In this step, however, create only the required locations and infrastructure. Do not perform any derivation or rendering.
   
   ## Preserve Existing Blockmaschine Setup
   
   This is important.
   
   Before modifying the repository, inspect the existing structure and understand how the initialized Blockmaschine project is organized.
   
   Preserve:
   
   - the existing BML library
   - BlockML configuration
   - CLI configuration
   - existing scripts
   - existing dependencies
   - existing README/library structure
   - existing project conventions
   
   Make the smallest reasonable changes necessary to add monorepo support and the two companions.
   
   The existing Blockmaschine project must continue to work after the conversion.
   
   ## Do Not
   
   Do not:
   
   - recreate `com.acme.workboard`
   - move the existing root BML library
   - create another authoritative BML library
   - model the Workboard domain
   - create Projects, Tasks, Users, Boards, Issues, or other domain blocks
   - derive the React SSOT
   - derive the Angular SSOT
   - render the Workboard application
   - introduce a BlockML compiler
   - implement Workboard UI
   - duplicate domain definitions between packages
   - introduce unnecessary infrastructure
   
   This step is strictly about **turning the existing Blockmaschine repository into a monorepo and adding the two companion shells**.
   
   ## Verification
   
   Before finishing:
   
   1. Verify that the existing Blockmaschine project still works.
   2. Verify that the existing `com.acme.workboard` BML library remains intact.
   3. Verify the npm workspace configuration.
   4. Install all required dependencies.
   5. Verify that the React companion builds successfully.
   6. Verify that the Angular companion builds successfully.
   7. Verify that both companions can be started independently.
   8. Verify that each companion has a clearly identifiable location for its future derived BML SSOT.
   9. Verify that no Workboard domain modeling or rendering has been performed.
   
   At the end, provide a concise summary containing:
   
   - the resulting repository structure
   - the workspace package names
   - commands for starting and building React
   - commands for starting and building Angular
   - locations reserved for the two derived BML SSOTs
   - any changes made to the root `package.json`
   - confirmation that the existing Blockmaschine setup and `com.acme.workboard` library were preserved
   

3. Agent

   Model the Workboard SSOT

   Turn the existing com.acme.workboard library into the authoritative Workboard model. Leave both companions untouched.

   Copy this prompt into a coding agent. Open it to read the full text.

   Agent prompt Copy Show prompt

   # Step 3 — Model the Workboard SSOT
   
   The repository is already a complete Blockmaschine monorepo.
   
   The previous steps have:
   
   1. initialized the Blockmaschine project and created the minimal authoritative BlockML library `com.acme.workboard`
   2. converted the repository into a monorepo and added empty React and Angular companions
   
   Your task in this step is **only to model the Workboard application in the authoritative root BlockML library**.
   
   Do not derive or render either companion application yet.
   
   ## Existing Repository
   
   The repository already contains:
   
   - the authoritative BlockML library `com.acme.workboard`
   - its existing `Library` definition and README
   - the complete Blockmaschine and BlockML CLI setup
   - the monorepo configuration
   - a React companion under `companions`
   - an Angular companion under `companions`
   - locations inside the companions reserved for their future derived BlockML SSOTs
   
   Treat all of this as the existing project structure.
   
   The React and Angular companions are intentionally still empty application shells.
   
   **Do not modify them in this step.**
   
   ## Goal
   
   Turn the existing minimal `com.acme.workboard` BlockML library into the authoritative semantic model for a small project and issue management application.
   
   The application should be comparable in scope to a small Jira-like Workboard.
   
   The model should be substantial enough to demonstrate BlockML as an application Single Source of Truth, while remaining small enough to understand as a tutorial example.
   
   Conceptually:
   
   ```text
   com.acme.workboard
   │
   ├── Workspace
   ├── Project
   ├── Issue
   ├── User
   ├── Label
   ├── Comment
   │
   ├── Status
   ├── Priority
   │
   └── application behavior and constraints
   ```
   
   This is a **semantic application model**, not a React model and not an Angular model.
   
   The authoritative model must not contain framework-specific concepts merely to accommodate one of the future companions.
   
   ## Understand the Existing BlockML Project First
   
   Before making changes, inspect the existing BlockML library and the BlockML documentation, examples, type definitions, and CLI capabilities available in the repository.
   
   Follow the established BlockML conventions rather than inventing a parallel structure or syntax.
   
   In particular, determine how the current BlockML version represents concepts such as:
   
   - Blocks
   - Properties
   - ValueTypes
   - Aggregations
   - Associations
   - Capabilities
   - constraints and validation
   - documentation and descriptions
   
   Use the actual facilities provided by the project.
   
   Do not invent unsupported BlockML syntax or concepts.
   
   ## Workboard Domain
   
   Model a small but coherent Workboard domain.
   
   The core domain should contain at least the following concepts.
   
   ### Workspace
   
   Represents the Workboard as a whole.
   
   It should provide access to:
   
   - projects
   - users
   
   ### Project
   
   Represents a project containing issues.
   
   Model appropriate information such as:
   
   - name
   - description
   - issues
   
   A project should make it possible to understand and work with its issue collection.
   
   ### Issue
   
   This is the central work item of the application.
   
   Model appropriate information including:
   
   - title
   - description
   - status
   - priority
   - assignee
   - labels
   - due date
   - comments
   
   Use proper BlockML relationships where concepts reference other modeled concepts.
   
   Do not reduce relationships such as assignee, labels, or comments to arbitrary strings if BlockML provides an appropriate structural mechanism.
   
   ### User
   
   Represents a person who can participate in the Workboard and be assigned to issues.
   
   Keep the user model intentionally small.
   
   ### Label
   
   Represents a reusable classification that can be assigned to issues.
   
   ### Comment
   
   Represents discussion attached to an issue.
   
   A comment should have enough information to identify its author and content.
   
   Keep it small; this example does not need to become a collaboration platform.
   
   ## Status and Priority
   
   Model status and priority as proper constrained domain concepts using the mechanisms provided by BlockML.
   
   The intended issue statuses are:
   
   ```text
   BACKLOG
   TODO
   IN_PROGRESS
   REVIEW
   DONE
   ```
   
   The intended priorities are:
   
   ```text
   LOW
   MEDIUM
   HIGH
   CRITICAL
   ```
   
   Do not encode these as unrestricted strings if BlockML provides an appropriate type mechanism.
   
   ## Application Behavior
   
   The model should demonstrate that BlockML can describe more than passive data structures.
   
   Where supported by the existing BlockML model, define meaningful capabilities for operations such as:
   
   - creating an issue
   - changing an issue's status
   - assigning an issue to a user
   - adding a comment
   
   Keep the behavior intentionally small and understandable.
   
   The goal is not to model every operation a real Jira-like system could support.
   
   The goal is to demonstrate the semantic relationship between **state and behavior**.
   
   ## Constraints
   
   Use appropriate BlockML constraints where they add meaningful semantics.
   
   Examples include:
   
   - required issue title
   - sensible title lengths
   - required project name
   - required comment content
   - valid status and priority values
   
   Do not add arbitrary validation merely to increase the amount of modeling.
   
   Constraints should express actual domain meaning.
   
   ## Documentation
   
   Add concise descriptions where they improve understanding of the model.
   
   The BlockML library should be understandable by both:
   
   - a human reading the model
   - an agent that will later derive companion-specific models from it
   
   Update the existing library README where appropriate so that it briefly explains the Workboard model and its role as the authoritative SSOT.
   
   Keep documentation concise. The model itself should remain the primary source of truth.
   
   ## Model Boundaries
   
   Keep the authoritative model independent from its future manifestations.
   
   Do not introduce concepts such as:
   
   - React components
   - Angular components
   - JSX
   - Angular templates
   - Material UI
   - Angular Material
   - CSS
   - routing libraries
   - frontend state-management frameworks
   - framework-specific services
   - generated source files
   
   The authoritative model describes **what the Workboard is**, not how React or Angular implements it.
   
   ## Companion Boundary
   
   The future pipeline is:
   
   ```text
   com.acme.workboard
           │
           ├──> React Derived SSOT
           │          │
           │          └──> React Artifact
           │
           └──> Angular Derived SSOT
                      │
                      └──> Angular Artifact
   ```
   
   This step modifies only:
   
   ```text
   com.acme.workboard
   ```
   
   The derived companion SSOTs will be created in later steps.
   
   Do not copy the authoritative model into either companion.
   
   Do not prepare framework-specific variations of the model yet.
   
   ## Scope
   
   Keep the example deliberately small.
   
   A good result should be rich enough to later support screens such as:
   
   - project overview
   - project board
   - issue detail
   - create/edit issue
   
   However, **do not model those screens simply because they will exist later** unless the existing BlockML architecture explicitly models application/UI semantics at the authoritative level.
   
   Prefer domain semantics over assumptions about future frontend implementations.
   
   Do not expand the example into:
   
   - authentication
   - permissions and role management
   - organizations or multi-tenancy
   - notifications
   - file attachments
   - time tracking
   - sprints
   - epics
   - advanced workflows
   - integrations
   - persistence infrastructure
   
   Those are intentionally outside the scope of this tutorial.
   
   ## Do Not
   
   Do not:
   
   - modify the React companion
   - modify the Angular companion
   - create either derived companion SSOT
   - generate React code
   - generate Angular code
   - implement UI
   - introduce a compiler
   - introduce persistence infrastructure
   - add a backend
   - add framework-specific concepts to the authoritative model
   - restructure the monorepo
   - recreate the BlockML library
   - replace existing Blockmaschine configuration
   
   This step is strictly about **turning the existing minimal root BlockML library into the authoritative Workboard application model**.
   
   ## Verification
   
   Before finishing:
   
   1. Validate the BlockML model using the existing BlockML tooling.
   2. Resolve all validation errors introduced by this step.
   3. Verify that the model follows the conventions of the existing BlockML project.
   4. Verify that all modeled relationships use appropriate BlockML semantics.
   5. Verify that status and priority are properly constrained.
   6. Verify that meaningful application behavior is represented where supported.
   7. Verify that the model contains no React-specific concepts.
   8. Verify that the model contains no Angular-specific concepts.
   9. Verify that neither companion was derived or rendered.
   10. Verify that the existing Blockmaschine project and monorepo setup still work.
   
   ## Result
   
   At the end, provide a concise summary containing:
   
   - the BlockML blocks and types that were created
   - the important relationships between them
   - the modeled capabilities
   - the modeled constraints
   - the files that were added or changed
   - the validation command used and its result
   - confirmation that neither companion was modified
   - confirmation that `com.acme.workboard` is now the authoritative Workboard SSOT
   
   The repository should now be ready for the next step:
   
   **derive the React-specific SSOT from `com.acme.workboard` and render the React companion from that derived model.**
   

4. Agent

   Derive and render the React companion

   Derive a React-specific BlockML SSOT from the Workboard model, then render the React application from that derived model. Leave the Angular companion untouched.

   Copy this prompt into a coding agent. Open it to read the full text.

   Agent prompt Copy Show prompt

   # Step 4 — Derive and Render the React Companion
   
   The repository is already a complete Blockmaschine monorepo containing an authoritative Workboard model and empty React and Angular companion applications.
   
   The previous steps have:
   
   1. initialized the Blockmaschine project and created the minimal authoritative BlockML library `com.acme.workboard`
   2. converted the repository into a monorepo and added React and Angular companions
   3. modeled the Workboard domain in the authoritative `com.acme.workboard` BlockML library
   
   Your task in this step is **only to derive the React-specific BlockML SSOT from the authoritative model and render the React companion application from that derived model**.
   
   Do not modify or render the Angular companion.
   
   ## Existing Repository
   
   The repository already contains:
   
   - the authoritative BlockML library `com.acme.workboard`
   - the complete Workboard domain model
   - the Blockmaschine and BlockML CLI setup
   - the monorepo configuration
   - a React companion under `companions`
   - an Angular companion under `companions`
   - a location inside the React companion reserved for its derived BlockML SSOT
   - a location inside the Angular companion reserved for its future derived BlockML SSOT
   
   The authoritative Workboard model is complete for the scope of this tutorial.
   
   **Treat it as read-only during this step.**
   
   Do not change the authoritative model merely to make React implementation easier.
   
   ## Goal
   
   Produce a complete React manifestation of the Workboard in two distinct stages:
   
   ```text
   com.acme.workboard
           │
           │ derive
           ▼
   React Derived SSOT
           │
           │ render
           ▼
   React Application Artifact
   ```
   
   Both transformations are performed by you as the agent.
   
   There is no compiler or deterministic code generator involved.
   
   The important architectural rule is:
   
   **Do not render the React application directly from the authoritative root model.**
   
   First derive a React-specific BlockML SSOT. Then treat that derived model as the immediate Single Source of Truth for the React application artifact.
   
   ## Phase 1 — Understand the Authoritative Model
   
   Before making changes, inspect the complete authoritative `com.acme.workboard` BlockML library.
   
   Understand:
   
   - its blocks and types
   - properties
   - aggregations
   - associations
   - capabilities
   - constraints
   - documentation
   - relationships between domain concepts
   
   Also inspect the existing React companion and the BlockML facilities available in the repository.
   
   Do not assume the model structure from this prompt if the actual authoritative model differs.
   
   The repository itself is the source of truth.
   
   ## Phase 2 — Derive the React SSOT
   
   Create the React companion's derived BlockML library in the location prepared for it during Step 2.
   
   This derived library should preserve the semantics of the authoritative Workboard model while enriching or adapting them with the information required to describe the React companion.
   
   The derived model may introduce application and presentation concepts that intentionally do not belong in the framework-independent root model.
   
   For example, where appropriate, it may describe concepts such as:
   
   - application structure
   - navigation
   - screens or views
   - board presentation
   - issue presentation
   - forms
   - user interactions
   - commands and actions
   - filtering
   - presentation-specific composition
   
   Use actual BlockML capabilities and conventions available in the repository.
   
   Do not invent unsupported BlockML syntax.
   
   ## Derived SSOT Semantics
   
   The React-derived model has a different lifecycle from the authoritative root model.
   
   The authoritative model:
   
   ```text
   com.acme.workboard
   ```
   
   is manually maintained and authoritative.
   
   The React-derived model is:
   
   - generated by an agent
   - derived from `com.acme.workboard`
   - specific to the React companion
   - the immediate SSOT for the React artifact
   - reproducible
   - disposable
   - safe to delete and regenerate
   
   It must never become a competing authoritative definition of the Workboard domain.
   
   Where domain semantics already exist in the root model, preserve them rather than independently redefining their meaning.
   
   ## React Application Scope
   
   Render a small but polished Workboard application from the derived React SSOT.
   
   The application should make the modeled domain tangible and demonstrate that a useful application can be manifested from the BlockML model.
   
   Implement the following core experience.
   
   ### Project Overview
   
   Provide an overview of the available projects.
   
   A user should be able to select a project and enter its Workboard.
   
   ### Project Board
   
   Provide a board-oriented view of the selected project's issues.
   
   Organize issues according to their modeled status:
   
   ```text
   BACKLOG
   TODO
   IN_PROGRESS
   REVIEW
   DONE
   ```
   
   Issue cards should expose useful modeled information such as:
   
   - title
   - priority
   - assignee
   - labels
   - due date where applicable
   
   The board should make the status model visually understandable.
   
   ### Issue Detail
   
   Provide a detailed view for an issue.
   
   Present the important information represented by the model, including:
   
   - title
   - description
   - status
   - priority
   - assignee
   - labels
   - due date
   - comments
   
   Expose modeled actions where appropriate.
   
   ### Create / Edit Issue
   
   Provide a usable form for creating or editing an issue.
   
   Respect the constraints represented by the model.
   
   The UI should make invalid or missing required input understandable to the user.
   
   ## Modeled Behavior
   
   Where the authoritative model defines capabilities, represent them meaningfully in the React application.
   
   Examples may include:
   
   - creating an issue
   - changing issue status
   - assigning an issue
   - adding a comment
   
   The application does not need a backend for this tutorial.
   
   Use a simple local/in-memory application state where persistence is required for the demonstration.
   
   Do not introduce backend infrastructure merely to simulate a production system.
   
   ## React Implementation
   
   Use the existing React companion created in Step 2.
   
   Use modern React and TypeScript practices consistent with the existing project setup.
   
   You may introduce appropriate React ecosystem dependencies where they materially improve the application, but keep the dependency set small.
   
   Prefer straightforward implementation over unnecessary abstraction.
   
   The resulting application should feel like a coherent small product rather than a collection of generated demo components.
   
   ## Design
   
   Create a clean, professional Workboard interface.
   
   The application should be visually polished enough to serve as a public BlockML example.
   
   Aim for:
   
   - clear information hierarchy
   - restrained visual design
   - readable typography
   - useful spacing
   - recognizable board columns
   - clear issue cards
   - consistent forms and detail views
   - responsive behavior where reasonable
   
   Do not attempt to clone Jira's visual design.
   
   This is the **Acme Workboard**, not a Jira skin.
   
   The visual design may be React-specific. Pixel-level equivalence with the future Angular companion is not required.
   
   Semantic equivalence is more important than identical implementation or styling.
   
   ## Sample Data
   
   Provide a small set of realistic sample data so the application is immediately useful when started.
   
   The sample data should exercise the important parts of the model:
   
   - multiple projects if appropriate
   - issues across different statuses
   - different priorities
   - users and assignees
   - labels
   - due dates
   - comments
   
   Keep the dataset small enough that the application remains immediately understandable.
   
   Do not pollute the authoritative root model with demo-instance data unless the existing model explicitly defines such data as part of its semantics.
   
   ## Source-of-Truth Discipline
   
   Maintain the following dependency direction:
   
   ```text
   Authoritative Workboard SSOT
               ↓
        React Derived SSOT
               ↓
         React Artifact
   ```
   
   Never reverse this relationship.
   
   Do not modify the authoritative model based on implementation details discovered while building React.
   
   Do not treat React source code as a source of domain truth.
   
   The React source is an artifact of the React-derived BlockML model.
   
   If the React implementation requires a presentation decision that is absent from the authoritative model, encode that decision in the React-derived SSOT where BlockML provides an appropriate representation.
   
   ## Angular Boundary
   
   Do not modify:
   
   - the Angular companion
   - the Angular derived SSOT location
   - Angular dependencies
   - Angular application code
   
   Angular will be handled independently in the next step.
   
   This separation is intentional.
   
   The later Angular agent should be able to start from the same authoritative Workboard SSOT without depending on decisions made for React.
   
   ## Do Not
   
   Do not:
   
   - modify the authoritative `com.acme.workboard` model
   - render React directly from the root model without creating the derived SSOT
   - create or modify the Angular-derived SSOT
   - implement the Angular application
   - introduce a BlockML compiler
   - introduce a backend
   - introduce a database
   - add authentication
   - expand the Workboard domain beyond the scope established by the authoritative model
   - duplicate domain semantics unnecessarily
   - turn the derived React model into an authoritative model
   - make the authoritative model depend on React
   - introduce unnecessary infrastructure
   
   This step is strictly about **deriving and rendering the React companion**.
   
   ## Verification
   
   Before finishing:
   
   1. Validate the derived React BlockML model using the existing BlockML tooling.
   2. Resolve all validation errors introduced by this step.
   3. Verify that the derived model is based on the authoritative `com.acme.workboard` model.
   4. Verify that React-specific application decisions are contained within the React companion.
   5. Verify that the authoritative Workboard model was not modified.
   6. Verify that the React application builds successfully.
   7. Verify that the React application starts successfully.
   8. Verify that the core Workboard experience is usable.
   9. Verify that modeled constraints are reflected appropriately in the UI.
   10. Verify that modeled capabilities have meaningful React interactions where applicable.
   11. Verify that the Angular companion remains untouched.
   12. Verify that deleting the derived React SSOT and React artifact would not destroy authoritative Workboard information.
   
   ## Result
   
   At the end, provide a concise summary containing:
   
   - the structure of the derived React BlockML SSOT
   - the important presentation/application concepts added during derivation
   - how those concepts relate back to the authoritative model
   - the React screens and interactions that were rendered
   - the React dependencies added
   - the files and directories created or changed
   - the BlockML validation command and its result
   - the React build command and its result
   - the command for starting the React companion
   - confirmation that the authoritative `com.acme.workboard` model was not modified
   - confirmation that the Angular companion was not modified
   - confirmation that the React application is an artifact of its disposable derived SSOT
   
   The repository should now be ready for the final step:
   
   **independently derive the Angular-specific SSOT from `com.acme.workboard` and render the Angular companion from that derived model.**
   

5. Agent

   Derive and render the Angular companion

   Derive an Angular-specific BlockML SSOT from the Workboard model, then render the Angular application from that derived model. Leave the React companion untouched.

   Copy this prompt into a coding agent. Open it to read the full text.

   Agent prompt Copy Show prompt

   # Step 5 — Derive and Render the Angular Companion
   
   The repository is already a complete Blockmaschine monorepo containing an authoritative Workboard model and a React and Angular companion.
   
   The previous steps have:
   
   1. initialized the Blockmaschine project and created the minimal authoritative BlockML library `com.acme.workboard`
   2. converted the repository into a monorepo and added React and Angular companions
   3. modeled the Workboard domain in the authoritative `com.acme.workboard` BlockML library
   4. independently derived the React-specific BlockML SSOT and rendered the React companion from it
   
   Your task in this step is **only to derive the Angular-specific BlockML SSOT from the authoritative model and render the Angular companion application from that derived model**.
   
   The React companion is already complete.
   
   Do not modify it and do not use it as the source for the Angular implementation.
   
   ## Existing Repository
   
   The repository already contains:
   
   - the authoritative BlockML library `com.acme.workboard`
   - the complete Workboard domain model
   - the Blockmaschine and BlockML CLI setup
   - the monorepo configuration
   - a completed React companion
   - a derived React BlockML SSOT
   - an Angular companion shell
   - a location inside the Angular companion reserved for its derived BlockML SSOT
   
   The authoritative Workboard model is complete for the scope of this tutorial.
   
   **Treat it as read-only during this step.**
   
   The existing React companion is also complete.
   
   **Treat the entire React companion as read-only during this step.**
   
   ## Goal
   
   Produce a complete Angular manifestation of the Workboard in two distinct stages:
   
   ```text
   com.acme.workboard
           │
           │ derive
           ▼
   Angular Derived SSOT
           │
           │ render
           ▼
   Angular Application Artifact
   ```
   
   Both transformations are performed by you as the agent.
   
   There is no compiler or deterministic code generator involved.
   
   The important architectural rule is:
   
   **Do not render the Angular application directly from the authoritative root model.**
   
   First derive an Angular-specific BlockML SSOT. Then treat that derived model as the immediate Single Source of Truth for the Angular application artifact.
   
   ## Independent Derivation
   
   The Angular companion must be derived independently from the authoritative Workboard model.
   
   Conceptually, the repository now represents two independent derivation paths:
   
   ```text
                       com.acme.workboard
                              │
                 ┌────────────┴────────────┐
                 │                         │
                 ▼                         ▼
        React Derived SSOT        Angular Derived SSOT
                 │                         │
                 ▼                         ▼
          React Artifact            Angular Artifact
   ```
   
   The Angular derivation must start from:
   
   `com.acme.workboard`
   
   It must **not** start from:
   
   - the React-derived SSOT
   - React components
   - React application structure
   - React source code
   - React styling
   - implementation decisions made during Step 4
   
   The purpose of this step is to demonstrate that multiple framework-specific manifestations can independently originate from the same authoritative BlockML model.
   
   ## Phase 1 — Understand the Authoritative Model
   
   Before making changes, inspect the complete authoritative `com.acme.workboard` BlockML library.
   
   Understand:
   
   - its blocks and types
   - properties
   - aggregations
   - associations
   - capabilities
   - constraints
   - documentation
   - relationships between domain concepts
   
   Also inspect the existing Angular companion and the BlockML facilities available in the repository.
   
   Use the actual authoritative model as your source.
   
   Do not assume its exact structure from this prompt.
   
   Do not use the React companion to reconstruct or reinterpret the domain model.
   
   ## Phase 2 — Derive the Angular SSOT
   
   Create the Angular companion's derived BlockML library in the location prepared for it during Step 2.
   
   This derived library should preserve the semantics of the authoritative Workboard model while enriching or adapting them with the information required to describe the Angular companion.
   
   The derived model may introduce application and presentation concepts that intentionally do not belong in the framework-independent root model.
   
   For example, where appropriate, it may describe concepts such as:
   
   - application structure
   - navigation
   - screens or views
   - board presentation
   - issue presentation
   - forms
   - user interactions
   - commands and actions
   - filtering
   - presentation-specific composition
   
   Use actual BlockML capabilities and conventions available in the repository.
   
   Do not invent unsupported BlockML syntax.
   
   ## Derived SSOT Semantics
   
   The Angular-derived model has a different lifecycle from the authoritative root model.
   
   The authoritative model:
   
   `com.acme.workboard`
   
   is manually maintained and authoritative.
   
   The Angular-derived model is:
   
   - generated by an agent
   - derived from `com.acme.workboard`
   - specific to the Angular companion
   - the immediate SSOT for the Angular artifact
   - reproducible
   - disposable
   - safe to delete and regenerate
   
   It must never become a competing authoritative definition of the Workboard domain.
   
   Where domain semantics already exist in the root model, preserve them rather than independently redefining their meaning.
   
   ## Angular Application Scope
   
   Render a small but polished Workboard application from the derived Angular SSOT.
   
   The application should make the modeled domain tangible and demonstrate that a useful Angular application can be manifested from the same authoritative BlockML model used for the React companion.
   
   Implement the following core experience.
   
   ### Project Overview
   
   Provide an overview of the available projects.
   
   A user should be able to select a project and enter its Workboard.
   
   ### Project Board
   
   Provide a board-oriented view of the selected project's issues.
   
   Organize issues according to their modeled status:
   
   ```text
   BACKLOG
   TODO
   IN_PROGRESS
   REVIEW
   DONE
   ```
   
   Issue cards should expose useful modeled information such as:
   
   - title
   - priority
   - assignee
   - labels
   - due date where applicable
   
   The board should make the status model visually understandable.
   
   ### Issue Detail
   
   Provide a detailed view for an issue.
   
   Present the important information represented by the model, including:
   
   - title
   - description
   - status
   - priority
   - assignee
   - labels
   - due date
   - comments
   
   Expose modeled actions where appropriate.
   
   ### Create / Edit Issue
   
   Provide a usable form for creating or editing an issue.
   
   Respect the constraints represented by the model.
   
   The UI should make invalid or missing required input understandable to the user.
   
   ## Modeled Behavior
   
   Where the authoritative model defines capabilities, represent them meaningfully in the Angular application.
   
   Examples may include:
   
   - creating an issue
   - changing issue status
   - assigning an issue
   - adding a comment
   
   The application does not need a backend for this tutorial.
   
   Use simple local/in-memory application state where persistence is required for the demonstration.
   
   Do not introduce backend infrastructure merely to simulate a production system.
   
   ## Angular Implementation
   
   Use the existing Angular companion created in Step 2.
   
   Use modern Angular and TypeScript practices consistent with the existing project setup.
   
   Prefer Angular-native concepts and patterns where appropriate.
   
   You may introduce appropriate Angular ecosystem dependencies where they materially improve the application, but keep the dependency set small.
   
   Prefer straightforward implementation over unnecessary abstraction.
   
   Do not imitate React architecture merely because the React companion already exists.
   
   The Angular companion should feel like a natural Angular application.
   
   ## Design
   
   Create a clean, professional Workboard interface.
   
   The application should be visually polished enough to serve as a public BlockML example.
   
   Aim for:
   
   - clear information hierarchy
   - restrained visual design
   - readable typography
   - useful spacing
   - recognizable board columns
   - clear issue cards
   - consistent forms and detail views
   - responsive behavior where reasonable
   
   Do not attempt to clone Jira's visual design.
   
   This is the **Acme Workboard**, not a Jira skin.
   
   The visual design may be Angular-specific.
   
   The Angular and React companions do not need to be pixel-identical.
   
   They should instead be **semantically equivalent manifestations of the same authoritative model**.
   
   ## Sample Data
   
   Provide a small set of realistic sample data so the application is immediately useful when started.
   
   The sample data should exercise the important parts of the model:
   
   - multiple projects if appropriate
   - issues across different statuses
   - different priorities
   - users and assignees
   - labels
   - due dates
   - comments
   
   Keep the dataset small enough that the application remains immediately understandable.
   
   Do not copy sample data from the React implementation merely for implementation convenience.
   
   Base the Angular sample data on the semantics of the authoritative model.
   
   Do not pollute the authoritative root model with demo-instance data unless the existing model explicitly defines such data as part of its semantics.
   
   ## Source-of-Truth Discipline
   
   Maintain the following dependency direction:
   
   ```text
   Authoritative Workboard SSOT
               ↓
       Angular Derived SSOT
               ↓
        Angular Artifact
   ```
   
   Never reverse this relationship.
   
   Do not modify the authoritative model based on implementation details discovered while building Angular.
   
   Do not treat Angular source code as a source of domain truth.
   
   The Angular source is an artifact of the Angular-derived BlockML model.
   
   If the Angular implementation requires a presentation decision that is absent from the authoritative model, encode that decision in the Angular-derived SSOT where BlockML provides an appropriate representation.
   
   ## React Boundary
   
   Do not modify:
   
   - the React companion
   - the React-derived SSOT
   - React dependencies
   - React source code
   - React styling
   - React configuration
   
   Do not refactor shared implementation code out of React and Angular merely because both applications implement similar semantics.
   
   For this example, the two derivation paths should remain clearly independent.
   
   Their common source is the authoritative BlockML model, not shared generated application code.
   
   ## Do Not
   
   Do not:
   
   - modify the authoritative `com.acme.workboard` model
   - render Angular directly from the root model without creating the derived SSOT
   - modify the React-derived SSOT
   - modify the React application
   - derive Angular from React
   - translate React components into Angular components
   - use React implementation decisions as Angular requirements
   - introduce a BlockML compiler
   - introduce a backend
   - introduce a database
   - add authentication
   - expand the Workboard domain beyond the scope established by the authoritative model
   - duplicate domain semantics unnecessarily
   - turn the derived Angular model into an authoritative model
   - make the authoritative model depend on Angular
   - introduce unnecessary infrastructure
   
   This step is strictly about **independently deriving and rendering the Angular companion**.
   
   ## Verification
   
   Before finishing:
   
   1. Validate the derived Angular BlockML model using the existing BlockML tooling.
   2. Resolve all validation errors introduced by this step.
   3. Verify that the derived model is based on the authoritative `com.acme.workboard` model.
   4. Verify that Angular-specific application decisions are contained within the Angular companion.
   5. Verify that the authoritative Workboard model was not modified.
   6. Verify that the Angular application builds successfully.
   7. Verify that the Angular application starts successfully.
   8. Verify that the core Workboard experience is usable.
   9. Verify that modeled constraints are reflected appropriately in the UI.
   10. Verify that modeled capabilities have meaningful Angular interactions where applicable.
   11. Verify that the React companion remains untouched.
   12. Verify that the Angular implementation does not depend on the React-derived SSOT or React artifact.
   13. Verify that deleting the derived Angular SSOT and Angular artifact would not destroy authoritative Workboard information.
   
   ## Result
   
   At the end, provide a concise summary containing:
   
   - the structure of the derived Angular BlockML SSOT
   - the important presentation/application concepts added during derivation
   - how those concepts relate back to the authoritative model
   - the Angular screens and interactions that were rendered
   - the Angular dependencies added
   - the files and directories created or changed
   - the BlockML validation command and its result
   - the Angular build command and its result
   - the command for starting the Angular companion
   - confirmation that the authoritative `com.acme.workboard` model was not modified
   - confirmation that the React companion was not modified
   - confirmation that Angular was derived independently from the authoritative model
   - confirmation that the Angular application is an artifact of its disposable derived SSOT
   
   The complete example should now demonstrate the full BlockML Companion workflow:
   
   ```text
                       com.acme.workboard
                       Authoritative SSOT
                              │
                 ┌────────────┴────────────┐
                 │                         │
                 ▼                         ▼
        React Derived SSOT        Angular Derived SSOT
                 │                         │
                 ▼                         ▼
          React Artifact            Angular Artifact
   ```
   
   Both companion-specific SSOTs and both application artifacts are replaceable.
   
   The authoritative `com.acme.workboard` BlockML library remains the shared source of truth.