Other Technical Spaces

Group-level literate source: ores.cmake.

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.

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).

Both are facets of this technical space.

There is no longer a unified "assets" technical space in the physical-space address graph — its templates were single-template families that each found a home elsewhere as the graph migration proceeded:

Of these, only the PlantUML ER diagram and the shell service-vars templates are currently reachable via any address or code path; the history-dialog .ui form was retired with the generic ores::qt::HistoryDialog.

Group-level literate source: ores.doc.

The Doc TS covers all org-mode document scaffolding: agile artefacts (sprint, story, task, capture), knowledge and reference documents (knowledge, recipe, runbook, skill, memory), entity model files, and this library's own self-hosting scaffolds. 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.

All four are facets of this 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.

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.

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.

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.