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 detail-dialog .ui form was retired with the generic history-dialog class, and the facet that housed it went with the desktop client.

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.

Component: ores.web (the browser interface).

TypeScript implements the web interface. Most of the component is authored by hand: the BFF that holds the NATS connection and the session, the browser client, and the wire-protocol plumbing. Two families are generated instead, from the same org entity models that drive the C++ facets, so the two projections cannot drift:

The generated tree is committed and covered by the codegen drift gate.

The component has no C++ parts, so it is not a compiled target. projects/ores.web/CMakeLists.txt only wires its npm build into the build, and compass services start launches the built BFF as ores.web.service.

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.

FPML (Financial Products Markup Language) data lives as XML under external/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.