Runtime Behavior of DBTable Skills
This chapter explains how a DBTable specification becomes executable code and clarifies which file is actually used when the subsystem handles a record at runtime.
1. From Source Specification to Generated Module
The execution path begins with a human-authored tskill.md document. This file is the source specification. It is not itself executed during create, read, update, or delete operations. When the subsystem prepares the skill, it parses the markdown file, validates the resulting structure, writes an intermediate specification file to specs/tskill.generated.mjs.md, and then invokes mirror-code-generator in order to produce the runtime module src/tskill.generated.mjs.
This sequence matters because it separates three distinct concerns. The markdown file captures human intent. The intermediate specification formalizes that intent in a generator-oriented representation. The generated module finally exposes executable JavaScript functions that can be imported by the subsystem. The process is therefore specification-driven from beginning to end.
tskill.md, while the subsystem executes the generated module from src/.2. What the Subsystem Actually Calls at Runtime
At runtime, the subsystem imports and calls the generated functions from src/tskill.generated.mjs. The markdown file remains the source specification, but the executable logic used during record preparation, validation, presentation, and delete checks comes from the generated module under src/.
In operational terms, the generated module exports functions such as prepareRecord, validateRecord, validateDelete, and presentRecord. The subsystem loads these functions and combines them with the surrounding execution context. That context includes the conversational controller, which interprets the user request as a create, update, select, or delete operation, and the database adapter, which performs the actual persistence work. The generated code therefore does not contain the database adapter itself. Instead, it contributes field-level and record-level logic, while the subsystem supplies the runtime services through which records are read, inserted, updated, or removed.
For a non-technical reader, the simplest interpretation is the following. A human writes rules in tskill.md. The system turns those rules into JavaScript. When the application later works with a record, it executes the JavaScript from src/tskill.generated.mjs, not the markdown file. The markdown file remains the authoritative source because future regeneration begins from it.
The generated files under src/ should not be edited directly, because later generation passes can overwrite them. The intended maintenance path is to update tskill.md and then regenerate the runtime module.
The practical implication of this design is that authoring, generation, and execution remain distinct phases. This distinction is what makes the subsystem inspectable. A reader can examine the source specification, the intermediate generated specification, and the runtime module as separate artifacts, each with a different role in the pipeline.