Other Technical Spaces

Codegen-supported technical spaces
Manually-authored technical spaces
See also

This document covers the technical spaces beyond C++ and SQL: three that are codegen-supported (CMake, Assets, Doc) and four that are manually authored (Emacs Lisp, Python, JavaScript, XML/FPML). For the MASD concepts see MASD, Physical Space, and Facet.

Codegen-supported technical spaces

CMake Technical Space

Group-level literate source: cmake_group.

The CMake TS covers the build system wiring: CMakeLists.txt files that define library targets, executable targets, Catch2 test binaries, and the PlantUML modeling targets. One facet with 8 archetypes.

The SRPP is the component build target pattern: every component has a root CMakeLists.txt and a src-level CMakeLists.txt. The src variant differs by component flavour (plain library / api library / core library / service — which adds an executable).

Archetype	Description
Component root	Top-level `CMakeLists.txt` (declares component, links targets)
Component src (plain)	Library-only `CMakeLists.txt`
Component src (api)	API-flavour library (exports macros, umbrella header)
Component src (core)	Core-flavour library (depends on matching api)
Component src (service)	Library + executable (the service binary)
Service src	Standalone service `CMakeLists.txt`
Component tests	Catch2 test binary target
Component modeling	PlantUML diagram generation target

Profile: --profile cmake. Literate source: cmake.

Assets Technical Space

Group-level literate source: assets_group.

The Assets TS covers non-code, non-SQL generated files that support other TSs: Qt Designer UI forms (.ui XML), PlantUML diagrams (.puml), and shell service variable files. One facet with 4 archetypes.

The Qt UI forms here complement the C++ Qt facet: the C++ TS generates the controller/model/window C++ classes; the Assets TS generates the .ui form files that Qt Designer reads.

Archetype	Description
Detail dialog `.ui`	Qt Designer XML for the single-record edit/view dialog
History dialog `.ui`	Qt Designer XML for the temporal history browser
PlantUML ER	`.puml` entity-relationship diagram
Shell service vars	Shell variable definitions for service configuration

Profile: --profile assets. Literate source: assets.

Doc Technical Space

Group-level literate source: doc_group.

The Doc TS covers all org-mode document scaffolding: agile artefacts (sprint, story, task, capture), knowledge and reference documents (knowledge, recipe, runbook, skill, memory), and entity model files. One facet with 20 archetypes. This is the TS that compass add commands and task new / story new delegate to internally.

The SRPP here is the org-mode document contract: frontmatter fields (#+title, #+type, #+level, #+filetags, #+created, #+updated), a :PROPERTIES: drawer with an ID, and the standard section structure for each document type.

Archetype	Description
Version doc	`doc_version.org` — version planning document
Sprint doc	`doc_sprint.org` — sprint with status, stories, charts
Story doc	`doc_story.org` — story with goal, tasks, decisions
Task doc	`doc_task.org` — task with goal, plan, review, result
Capture	`doc_capture.org` — product backlog inbox item
Knowledge doc	`doc_knowledge.org` — knowledge article
Recipe	`doc_recipe.org` — step-by-step how-to
Runbook	`doc_runbook.org` — operational procedure
Skill	`doc_skill.org` — Claude Code skill document
Memory	`doc_memory.org` — project memory entry
Investigation	`doc_investigation.org` — open-ended investigation
Release notes	`doc_release_notes.org` — sprint release notes
Manual chapter	`doc_manual.org` — user manual chapter
Product identity	`doc_product_identity.org` — product identity page
Component overview	`doc_component.org` — component `component_overview.org`
Entity org-model	`doc_entity_org.org` — entity model file (authored route)
Field group org-model	`doc_field_group.org` — nested value struct model file
Dataset overview	`doc_dataset.org` — dataset documentation
Facet doc	`doc_facet.org` — facet reference document
Template group doc	`doc_facet_group.org` — template group reference document

Profile: --profile doc. Literate source: doc.

Manually-authored technical spaces

These TSs have no codegen coverage in ORE Studio. All artefacts are written by hand (or by an LLM acting as the author, not as the generator). There is no facet catalogue and no archetype table for these TSs.

Emacs Lisp Technical Space

Components: ores.lisp, ores.compass.

Emacs Lisp is used for two purposes: ores.lisp provides the literate programming infrastructure (org-babel tangle for settings, skills, and templates; the ores-build-settings.el and ores-build-skills.el tangle scripts), and ores.compass provides the developer toolkit (compass commands, agile artefact scaffolding, journal, PR workflow).

No code generation is applied to Lisp artefacts — they are authored directly. The Lisp TS is a dependency of the build system (CMake invokes Emacs in batch mode for tangle targets), not of the entity codegen projection.

Python Technical Space

Component: ores.codegen.

Python is the implementation language of ores.codegen — the generator itself. It is not self-hosting: the Python artefacts are not generated by the system, they implement the system. The Python TS is therefore entirely manually authored and has no presence in the PMM.

JavaScript Technical Space

Component: ores.org-js (agile dashboard).

JavaScript is used for the ores.org-js agile board — a browser-side visualisation of the org-mode agile data exported as graphdata.json. All JavaScript is manually authored. No codegen coverage.

XML / FPML Technical Space

Component: ores.fpml.

FPML (Financial Products Markup Language) data lives as XML in ores.fpml. These files are input data to the system — they feed the automated populate codegen route (the ores.codegen parser reads FPML XML and derives SQL populate scripts). The XML artefacts themselves are not generated; they are sourced from the FPML standard and maintained manually.