# MSet Instruction Author 07 - Resource contracts and text authoring Status: **canonical-development** Branch: **MSet 64-bit** Current product: **MSet 2026 by GRAPHICO** Format covered: **MSet 2026 native instruction format 2026.1 plus legacy-readable packages** ## Purpose This is the seventh required module for an LLM that authors or reviews MSet 64-bit instructions. It defines **resource dependency discipline** and a safe fallback strategy for text authoring when a named TextStyle is not known to exist. The central rule is simple: > **Do not invent named resources. Use a named resource only when the target environment is known or explicitly declared to provide it.** This applies to TextStyles, levels, cells, custom line styles and other named environment resources. ## 1. Resource knowledge states Before emitting a named resource, classify it into one of these states: 1. **Known existing** - the resource is present in a supplied/inspected target environment, a verified package, an explicit resource list, or current runtime evidence. 2. **Declared/provisioned** - the user or project contract explicitly says that this resource will be created/provided under that exact name. 3. **Unknown/invented** - the model merely chose a plausible name without evidence that the target environment provides it. A finished instruction may use states 1 and 2. It must not silently use state 3. A declared/provisioned resource is a legitimate environment dependency even if it has not been physically installed yet. Record that dependency explicitly. ## 2. TextStyle policy TextStyles are the modern and preferred way to carry a coordinated text definition **when the style is known to exist or is explicitly guaranteed by the environment contract**. Therefore: - if the user supplies a list of valid TextStyles, prefer those styles when they fit the task, - if a project says that a TextStyle with an exact name will be prepared, the instruction may depend on it and must list that dependency, - if no TextStyle inventory or guarantee exists, **do not fabricate a style name** such as `Popis_Std` merely to make the instruction look complete, - absence of a known TextStyle is not a reason to abandon text authoring; use evidenced explicit text attributes instead. The command mechanism `textstyle active ` may be valid, but the **name** is an environment resource and must pass the resource check above. ## 3. Explicit text fallback when no TextStyle is known GRAPHICO supplied historical MSet instructions and explicitly reaffirmed the following authoring pattern as the intended fallback when no prepared TextStyle is available: ```xml place note;ft=23;th=1.5;tw=1.5;active txj cc ``` The important pattern is not that every text must use exactly these values. The important pattern is that text can be defined from **partial text/tool settings** rather than from an invented named TextStyle. **Module 08 CONNECT-safe normalization applies to all new MSet 2026 XML:** historical `pla ...` placement spellings are evidence only; author the corresponding new command with full `place ...`. Useful evidenced text-building tokens/patterns in the supplied GRAPHICO material include: ```text ft= th= tw= active txj place dialogtext place dialogtext above place dialogtext below place note place text ``` Evidence classification: - `th=` and `tw=` are also part of the current MSet 2026 standard text-scale substitution contract from module 03, - `ft=` and `active txj ...` are GRAPHICO-supplied authoring patterns with strong historical real-instruction evidence. Historical sources use abbreviated `pla dialogtext` / `pla note` / `pla text`; module 08 requires canonical new MSet 2026 output to normalize these to `place dialogtext` / `place note` / `place text`. Treat exact host behavior/value mappings as environment/runtime-sensitive until specifically verified in the current host, - exact font numbers and justification codes are values, not universal semantic names. Do not invent a font number or justification code when the target environment/standard has not supplied or evidenced it. ## 3A. `above` / `below` placement is relative to an element GRAPHICO clarified the semantic meaning of the evidenced text placement forms: ```text place dialogtext above place dialogtext below ``` For current authoring guidance, these forms mean placement **above or below an element**. They should not be captioned as a generic relation to a point. Semantically consistent UI wording is, for example: ```text Poloha k elementu Nad elementom Pod elementom ``` This clarification affects captions/context, not the Group -> Feature composition model. Module 06 remains authoritative for the promise/effect/context check. ## 4. Tool/setup may live in a Group; a Feature may contain only the delta The historical GRAPHICO instructions provide an important semantic pattern that is compatible with current Group -> Feature composition: the text tool and common setup may be inherited from a Group while a Feature supplies only a size, alignment or literal text delta. Example pattern from historical GRAPHICO material. Values such as `lv=5`, `co=3`, `lc=0` and font/size numbers here prove the composition pattern only; they do not establish a portable project resource mapping for new authoring: ```xml lc=0;wt=0;ft=0;active txj cc;place dialogtext co=3;lv=5 th=1.5;tw=1.3 th=1;tw=0.8 ``` The child Feature is meaningful even though it does not repeat `place dialogtext`: the effective command inherits the tool and common settings from its ancestors. This is exactly why module 06 reviews **effective command + context**, not only the local Feature text. ## 5. Literal ready-made text is also a valid contextual Feature Another established historical pattern places `place text` and common text attributes in a Group, then uses child Features whose local command is only the literal text to be inserted. Conceptually: ```xml ft=...;th=...;tw=...;active txj ...;place text parkovisko chodník ``` Again, the local Feature fragment is not a complete standalone MicroStation operation; the **effective Group -> Feature command** is the operation. Do not generalize arbitrary historical literal-text syntax beyond what the target host accepts. Use this as a composition/semantic pattern and runtime-test new variants when needed. ## 6. Named levels, cells and custom line styles follow the same rule The TextStyle rule is a specific case of the wider resource contract. Do not silently invent: - `lv=Some_New_Level` when no such level is known or declared, - a cell name when the cell library/environment does not guarantee it, - a custom line style name/number when the target resource does not guarantee it, - a TextStyle name that merely sounds appropriate. Allowed sources of resource knowledge include: - an explicit list supplied by the user, - an inspected workspace/DGN/DGNLIB/resource package, - a runtime-verified current package, - a project contract that says a named resource will be provisioned. If the required resource is not known, either: - use an evidenced resource-independent alternative, - ask for/propose a resource contract when the task allows clarification, - or clearly report that the finished environment-ready instruction cannot be completed without that dependency. ### 6A. Cell identity and cell type are separate resource facts For a cell, knowing the exact resource name is not always enough. When authoring depends on whether the cell inherits active symbology, stays view independent, rotates with the view or exposes internal snap points, also establish whether the resource is a MicroStation **Point Cell** or **Graphic Cell**. The general Bentley-documented behavior is published on demand as `reference.microstationCells`. Do not duplicate or reinvent those host rules inside a project/STN catalogue. A domain catalogue may state that a particular resource is `B` (Point) or `G` (Graphic) and then cross-reference the general MicroStation cell behavior. ## 7. Prefer modern named resources when they are actually available This module does **not** say that explicit `ft/th/tw/...` text is more modern than TextStyles. It is a fallback. Preferred order for text authoring is: 1. use a suitable **known/guaranteed TextStyle** when the target environment provides one, 2. otherwise use evidenced explicit text attributes/tool settings, 3. never invent a TextStyle name to bridge missing environment knowledge. The same principle applies generally: use the target environment's real resources when known; avoid fake dependencies when they are not. ## 8. Resource dependency ledger For a from-scratch instruction, list every named environment dependency and its evidence/source. At minimum classify: ```text resource type | exact name/value | status | source/guarantee ``` Examples of valid statuses: ```text known-existing project-will-provision runtime-verified user-supplied historical-example-only unknown -> not allowed in finished instruction ``` If the instruction contains a named resource that cannot be placed into an allowed state, redesign or report the gap. ## 9. Text authoring review checklist Before accepting a text branch, ask: 1. Is a TextStyle being used? If yes, how do we know that exact style exists or will be provisioned? 2. If no TextStyle is known, can the intended text be expressed with evidenced explicit attributes? 3. Are font and justification values themselves known, supplied or evidenced rather than guessed? 4. Does the effective command activate/modify the intended text workflow in context? 5. Are `th=`, `tw=`, `tx=` or `ls=` being scale-processed by module 03 as intended? 6. Is any `lc=` baseline causing a `LINESTYLE SET SCALE` side effect that is unnecessary or surprising for the text branch? 7. Are environment dependencies listed separately from MSet syntax and host-key-in evidence? ## 10. Evidence boundary for the GRAPHICO legacy examples `Georeal_GP.xml` and `Georeal_PO.xml` are valuable real historical instructions supplied by GRAPHICO. They strongly support composition patterns such as explicit text attributes, text tool setup in Groups and child Feature deltas. They are **historical evidence**, not a blanket claim that every old key-in/value is runtime-verified on MicroStation 2026. Use only the patterns/rules reconciled in this module unless a specific key-in receives stronger current evidence. The original historical source spelling is `pla note;ft=23;th=1.5;tw=1.5;active txj cc`. GRAPHICO reaffirmed this as evidence for the no-TextStyle fallback pattern, and module 08 establishes the canonical CONNECT/MSet 2026 authoring spelling as `place note;ft=23;th=1.5;tw=1.5;active txj cc`. ## Current boundary This module defines resource-contract discipline and text authoring fallback patterns. It does not provide a complete MicroStation 2026 font/justification/resource catalogue. Exact available TextStyle names, font mappings, level names, cells and custom line styles remain target-environment data unless explicitly published as part of a verified resource catalogue.