# MSet 2026 / 64-bit Instruction Author transport bundle releaseId: `20260919-v35` knowledgeVersion: `2026.09.19-v35` branch: `64` track: `instruction-author` bundleSchemaVersion: `2026.1` canonicalManifest: `https://www.graphico.sk/mset/ai/releases/20260919-v35/64/manifest.json` core: `https://www.graphico.sk/mset/ai/releases/20260919-v35/64/core.md` requiredPublishedModulesCount: `10` keyinReference: `https://www.graphico.sk/mset/ai/releases/20260919-v35/64/microstation-keyins.txt` sourceCount: `12` payloadUtf8Bytes: `169437` payloadSha256: `B012EFD7BB12FAF98E04D2749A5ED0B3DC0E13E666C8FBD2C47A424071BF580C` completionMarker: `` This file is a deterministic transport artifact for AI clients that cannot reliably follow URLs discovered inside fetched manifests. It contains the LF-normalized UTF-8 text of the exact current core.md followed by every requiredPublishedModules document in immutable-manifest order and then the exact current MicroStation key-in text/plain reference published as reference.keyins. Each source section declares its own UTF-8 byte length and SHA-256; the payload declares aggregate integrity and the file ends with the exact completionMarker above. The complete bundle UTF-8 byte length and SHA-256 are declared as learningTracks.instruction-author.transportBundle.bundleUtf8Bytes and .bundleSha256 in the current 64-bit manifest. Treat the bundle as INCOMPLETE if the terminal marker is absent or any declared integrity value fails. The immutable manifest remains the canonical release index. # MSet 64-bit Core Knowledge Status: **canonical-development** > **Status meaning:** `canonical-development` describes the maturity/status of the published MSet AI Hub knowledge content for this branch. It is **not** the commercial, release, support, runtime, or product status of MSet 2026. Do not describe MSet 2026 itself as being in `canonical-development`. Current product: **MSet 2026** This document is the mandatory core for the modern 64-bit MSet knowledge branch. ## Core rules - Work only within the 64-bit branch unless the user explicitly requests comparison or migration. - Treat published canonical rules as authoritative over examples. - A working example is evidence of runtime behavior, not automatically a recommendation for new authoring. - MSet instructions may be multi-file packages. Do not ignore DTD, entity, include or support files referenced by the entry XML. - Every MSet instruction must have a DTD. A deliberately self-contained single XML uses an internal DTD subset. A DTD-less XML is not a valid MSet instruction for authoring purposes, even if a permissive parser path might load it. - In a newly authored `Group`, normally put nested Groups before direct Features; intentional workflow-driven exceptions are allowed. - When descendant Features depend on active graphical attributes, establish a deterministic baseline in the nearest useful common Group; do not duplicate the same reset in every Feature. Use only evidenced host setters. - A Feature is a meaningful user action, not necessarily a new tool activation. For every authored Feature, check semantic consistency between `Cpt`, effective command, parent Group context and any active-tool/state assumption. - Match the user-requested XML/output scope exactly. A local `` fragment is not the same artifact as its effective Group -> Feature command. If the user asks for only a Feature snippet, return only that local Feature fragment; do not synthesize ancestor Groups, placeholder resources, or copy inherited/effective command pieces such as `place cel rel` into the Feature merely to make it look standalone. Add such syntax only when the user explicitly asks for a standalone executable Feature or verified source/context requires it locally. - MSet authoring is intent-first: for primary working branches, prefer domain/user actions whose effective commands establish the required CAD state and tool. Modifier/state Features remain valid as deliberate presets, adjustments, diagnostics or expert controls; do not make a low-level attribute palette the default workflow without a reason. - Keep format validity, command validity, runtime evidence, authoring quality and domain correctness distinct. Absence of authoritative evidence is not permission to infer syntax or resource meaning. - Do not force graphical baselines onto non-graphical or intentionally state-preserving actions; apply hygiene only where the Feature depends on that state. - Remember that `lc=` (including `lc=bylevel`) triggers standard line-style auto scale processing. - Do not invent Bentley key-ins. Prefer documented or GRAPHICO runtime-verified entries from the reference catalogue, existing verified package commands, or explicit user-supplied syntax. - For new MSet 2026 authoring, prefer the full canonical MicroStation command when its exact current form is established. Keep supported defined shorthands/assignment forms when they are part of the host or MSet substitution contract; do not mechanically expand `TH=`/`TW=`/`TX=`/`LC=`-style forms merely because they are short. Preserve historical prefix spellings as evidence/backward-compatible source and do not guess unknown expansions. Module 08 owns this distinction. - Do not invent named environment resources. Use TextStyles, levels, cells, custom line styles and similar resources only when they are known to exist or explicitly declared to be provisioned; otherwise prefer evidenced resource-independent/explicit settings and list remaining dependencies. - For text authoring, prefer a suitable known/guaranteed TextStyle; when none is known, use evidenced explicit text attributes/tool settings instead of fabricating a style name. - Geometry command evidence and authoring preference are separate. For ordinary general linework, `place smartline` is the preferred default; `place line` is single-segment-oriented and `place lstring` is situational when LineString/exact element-type intent matters. - Module 09 contains current GRAPHICO MicroStation 2026 evidence for `place block rotated` and interactive `place cir`; `place cir edge` is a separately observed three-point/circumference variant and must not be substituted for the interactive-radius workflow. - Optional root `TextColor` and `BackgroundColor` define per-instruction MSet UI appearance in canonical `#RRGGBB` form; they do not change `FormatVersion="2026.1"` and are not CAD element symbology. - The external URL action `$ % "https://..."` is runtime-verified in MSet 26.11.0.4 / MicroStation 2026. New instructions normally place groups of web links on a dedicated utility Page rather than mixing them into drawing-tool branches. - The same external-launch syntax is not automatically canonical for local files, folders or configuration-variable expansion; those cases remain unverified until separately exercised on the current runtime. - The Instruction Author transport bundle is complete only when its release/version, source count, payload integrity metadata and terminal completion marker agree with the current 64-bit manifest. The manifest also publishes SHA-256 and UTF-8 byte length for the complete bundle; reject or fall back from a truncated/mismatched transport artifact. A validated current bundle also embeds the exact current MicroStation `reference.keyins` text/plain reference after the ten required modules, so a restricted client that already loaded the complete bundle does not need a second URL fetch for those key-in semantics. - `reference.keyins` points to a concrete immutable reference file, not a directory placeholder. Use it as an evidence index; it does not authorize commands beyond the evidence labels it records. When the current validated Instruction Author bundle is already loaded, its embedded key-in source is the same authoritative reference and satisfies this dependency. - Before editing an instruction, inspect the branch manifest and load every required module for the Instruction Author track. - The branch manifest may advertise optional on-demand integration tracks. Load one only when the user's task depends on that integration; do not treat an optional integration as a general MSet prerequisite. - When a task materially concerns MicroStation Configuration, WorkSpace, WorkSet, project-environment `.cfg`, Standards/resource ownership or resolution, environment diagnostics, shared/network deployment, or V8i Project/PCF migration, load the on-demand `project-environment` track. Keep it out of ordinary instruction-authoring bootstrap work. - For questions or instruction work involving iNGs_Geo / `ig_*`, load the published `ings-geo-integration` track and its iNGs_Geo key-in reference. Keep the unresolved `ig_preber` versus vendor-documented `ig_preberprvok` discrepancy explicit until new evidence resolves it. - For questions materially concerning the Bentley standard/default color table, load the published standard-color reference instead of answering from generic model memory. Every human color name -> numeric `co=` conversion is a fresh lookup operation: explicitly consult the currently authoritative mapping again, including follow-up turns; never emit a remembered index. Preserve the pending requested color across applicability confirmation (`yes/no` confirms the table choice, not a different color), and cross-check name -> index -> RGB before emission. `BG` is a separate background entry, not numeric index 255; project/DGN-specific tables override the generic reference. - When Point Cell versus Graphic Cell behavior matters, load the general MicroStation cells reference. If its Markdown cannot be retrieved, actively use the validated `microstation-cells.txt` fallback before declaring the host reference unavailable. Keep host behavior separate from domain catalogues that only identify a cell as Point or Graphic. - For STN 01 3411 / `STN013411` / `STN013411_plus` symbology work, load the on-demand STN track and resource catalogue. If required Markdown retrieval fails, actively use the validated STN text/plain bundle; because that bundle contains both the STN resource catalogue and the general Point/Graphic Cell reference, a separate failed cells-Markdown fetch must not suppress an exact resource answer already evidenced by the bundle. Project/directive-specific symbol sets take precedence; the shared set is the practical default only when no stronger resource contract applies and availability is established. - Before declaring authoring/editing complete, reopen and verify the exact XML/ZIP artifact that will be returned; the requested change must be present in that artifact. During an already-established task, a newly supplied/re-supplied task-specific file is normally the current input revision and the same task continues unless the user changes it or genuine ambiguity/conflict appears. - `readyForFullAuthoring=true` means the core standard-mode MSet instruction/package contract is complete; it does not certify unknown key-ins, Annotation Scale, historical `$M(...)`, or untested environment-specific commands. ## Published learning track ### MSet Instruction Author Status: **complete for current standard-mode authoring** Published required modules: 1. `learn/instruction-author/01-concepts-and-package.md` 2. `learn/instruction-author/02-command-composition.md` 3. `learn/instruction-author/03-scale-and-substitutions.md` 4. `learn/instruction-author/04-safe-editing-and-errors.md` 5. `learn/instruction-author/05-good-authoring-practices.md` 6. `learn/instruction-author/06-semantic-context-review.md` 7. `learn/instruction-author/07-resource-contract-and-text-authoring.md` 8. `learn/instruction-author/08-connect-safe-keyin-forms.md` 9. `learn/instruction-author/09-basic-geometry-and-placement-patterns.md` 10. `learn/instruction-author/10-instruction-appearance-and-external-links.md` After all ten modules, an LLM may read, explain, validate, create and safely modify MSet 2026 instruction packages within the published scope. Bentley/application key-in validity remains evidence-gated. Annotation Scale and historical `$M(...)` control macros remain outside this track. ## Published on-demand knowledge ### MSet / iNGs_Geo integration Status: **published; load only when relevant** This track documents only the iNGs_Geo cooperation boundary used by MSet: orientation, availability/startup, current MSet usage, evidence gaps and the vendor-documented `ig_*` interface. iNGs_Geo remains optional. The track does not replace the complete iNGs_Geo user manual. ### STN013411 / STN013411_plus symbology Status: **published; load only when relevant** This track documents the shared GRAPHICO/iNGs MicroStation map-symbology resources used by MSet when no project-specific cell/line-style contract takes precedence. It keeps the STN 01 3411 semantic layer, the `STN013411` MicroStation implementation, the non-normative `plus` extensions and concrete MSet usage separate. ### General MicroStation host references The KB may publish small, MSet-relevant MicroStation references instead of duplicating host behavior inside every domain track. Current examples are the Bentley standard/default color table and Point Cell versus Graphic Cell behavior. These are on-demand references, not an attempt to reproduce the complete MicroStation documentation. # MSet Instruction Author 01 - Concepts and instruction packages 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 first required module for an LLM that will read, explain, create, or modify an MSet 64-bit instruction. After this module, the model should understand what an MSet instruction is, how an instruction package is organized, which XML nodes form the visible instruction tree, and which files must be inspected before editing. This module does **not** yet teach full command composition, scale substitutions, Bentley key-in syntax, or Annotation Scale behavior. Do not claim full MSet Instruction Author capability after reading this module alone. ## Source authority For the 64-bit branch, use this precedence when sources disagree: 1. current MSet 2026 runtime/parser behavior and current contract tests, 2. current MSet 2026 specifications and accepted project decisions, 3. current runtime-verified MSet 2026 instruction packages, 4. MSet 10 manual and other legacy documentation. Do not import MSet 32-bit/V8i rules unless the user explicitly requests comparison or migration. ## 1. What is an MSet instruction? An MSet instruction is XML content that defines both: - the visible command structure presented by MSet, and - command fragments that MSet can send to the active Bentley host. The XML entry document is consumed by MSet and converted into the runtime instruction model. An instruction may be a single XML file, but real instructions can also be multi-file packages. ## 2. An instruction may be a package Do not assume that the entry XML contains the complete instruction definition. A package may contain: - the entry `.xml` file, - a DTD file, - external entity files such as `.ent`, - XML fragments such as `.ixml`, - other support files referenced by the XML or entities. A current runtime-verified package uses this shape: ```text MSet_Polohopis.xml MSet_Polohopis/ _mset.dtd _mset.ent texty.ent chranicky.ixml formaty.ixml popis1.ixml popis2.ixml popis3.ixml ``` The entry XML references files below `MSet_Polohopis/`. Those files can in turn reference other files or define entities that expand into command fragments or complete XML node fragments. ### Editing rule Before modifying an instruction package: 1. identify the entry XML, 2. inspect its DTD/entity declarations, 3. follow all relevant external entity/include references, 4. locate the real source of the content that must change, 5. preserve meaningful relative paths and package structure. Do not edit only the expanded appearance of a package if the actual source is an entity or included fragment. ## 3. Relative paths are part of the package contract External DTD/entity/include references are resolved relative to the instruction document and its referenced files. Therefore, when moving, copying, or returning a modified package: - preserve the directory layout when relative references depend on it, - do not flatten package files without deliberately rewriting and validating all affected references, - treat the complete package as one logical artifact. ## 4. Preserve the existing encoding Legacy documentation describes MSet instructions as ANSI text. Current MSet 2026 does not impose one universal source encoding for every instruction. The current runtime-verified `MSet_Polohopis` package explicitly uses `windows-1250` and is supported by MSet 2026. ### Canonical editing rule Preserve the existing encoding of each instruction/package file unless the user explicitly requests an encoding migration and the migrated package is validated. Do **not** assume that every MSet 2026 instruction must be UTF-8. Do **not** assume that every new MSet 2026 instruction must be Windows-1250. ## 5. Entry XML and Signum The XML root element must be `Instruction`. For MSet 2026 native-format instructions, the current supported format version is: ```xml FormatVersion="2026.1" ``` A missing `FormatVersion` is accepted as legacy compatibility mode. Do not invent another format version. The instruction Signum is not stored as an XML attribute. It is derived from the entry XML filename without its extension and converted to upper case. Example: ```text MSet_Polohopis.xml -> MSET_POLOHOPIS ``` `DisplayName` is an optional human-facing root attribute. For a new native-format instruction, prefer an explicit descriptive `DisplayName`. MSet 2026 also supports optional Instruction-level appearance metadata: ```text TextColor BackgroundColor ``` The canonical authoring representation is six-digit RGB hex (`#RRGGBB`). These attributes affect the MSet instruction UI only; they are not MicroStation element symbology and they are not named Bentley resources. Because both attributes are optional metadata, their addition does **not** change the native format number: `FormatVersion="2026.1"` remains current. When present and valid, Instruction-level colors take precedence over the per-user appearance fallback for that instruction. When absent, the existing user/default appearance remains in effect. Schematic example: ```xml ... ``` This is a structural example only; it is not a complete package template. ### DTD is mandatory **Every MSet instruction must have a DTD.** The DTD is part of the MSet instruction contract, not an optional style convention. Use the DTD form that matches the package shape: - multi-file instruction package -> keep the DTD/entity structure as package files and preserve all relative references, - deliberately self-contained single-file instruction -> embed the current MSet instruction DTD as an internal DTD subset. A DTD-less XML document is **not a valid MSet instruction for authoring purposes**, even if a permissive parser path might technically load such XML. Do not create or return an MSet instruction without its DTD. Current MSet 2026 DTD contract: ```xml ]> ``` A self-contained MSet 2026 instruction using this internal subset was runtime-loaded successfully in MSet `26.11.0.4` inside MicroStation 2026 on 2026-08-24. The same test also confirmed that its declared `` were accepted and the active MSet scale could be changed. This runtime evidence confirms that the internal-subset form is supported for a self-contained native instruction. The product authoring contract still requires a DTD in every MSet instruction. ## 6. Core XML node types The visible instruction hierarchy is built from these concepts: ```text Instruction +- optional Scales +- Page +- Group | +- Group | | +- Feature | +- Feature +- Feature ``` The exact allowed structure is governed by the instruction format/DTD and current parser rules. ### `Instruction` `Instruction` is the root node of the entry document. It can contain Pages and may contain an optional `Scales` element. Direct command text on `Instruction`, when present, is a lifecycle command executed when the instruction becomes active. It is not inherited into Feature effective commands. ### `Scales` `Scales` is optional. If present, its current parser rules require positive integer scale values and a positive `PrimaryScale` that is included in the declared scale list. A valid MSet 2026 instruction may omit `Scales`; MSet then uses its runtime defaults. Detailed scale behavior is taught in a later module. ### `Page` A `Page` represents one named page/tab in the MSet UI. Current rules: - `Cpt` is required, - a Page contains instruction-tree content, - direct Page command text is a Page lifecycle command, - the Page command is separate from Feature effective command composition. The first Page is also activated when an instruction initially becomes active. ### `Group` A `Group` is a navigational and inheritable command scope. Current rules: - `Cpt` is required, - a Group may contain nested Groups and/or Features, - a Group may contain its own local command fragment, - Group command fragments can contribute to descendant Feature execution. Detailed inheritance and composition are taught in the command-composition module. #### Canonical child ordering inside a `Group` The DTD permits `Group` and `Feature` children to be interleaved. For newly authored instructions, however, use this **default UI-authoring convention**: 1. local Group command text immediately after the opening `Group` tag, 2. nested `Group` children, 3. direct `Feature` children. In short: **Groups first, Features second, as a rule.** This is a style convention, not a parser restriction. An intentional exception is allowed when a different order clearly improves the user workflow. Do not reorder an existing instruction merely for aesthetics unless the user requested that cleanup. ### `Feature` A `Feature` is an executable leaf in the instruction tree. Current rules: - `Cpt` is required, - a Feature may contain command text, - a Feature may not contain child instruction nodes, - selecting a Feature causes MSet to build and dispatch its effective command. A Feature with empty local command text is valid. It may still receive effective behavior from ancestor Groups. ## 7. `Cpt` is display text, not a stable technical identifier `Cpt` supplies the visible caption of a Page, Group, or Feature. Do not assume captions are globally unique. Real instruction packages can contain repeated captions. When describing or editing a node, identify it by structural context/path when necessary, for example: ```text Page "Kreslenie" -> Group "400 Kataster nehnutelnosti" -> Group "402 UO" -> Feature "Hranica parcely" ``` Do not invent a technical ID from `Cpt` unless the format explicitly defines one. ## 8. Package-aware editing rules When an LLM is asked to modify an MSet instruction: - inspect the complete relevant package first, - preserve the entry filename unless the requested change requires a rename, - remember that renaming the entry XML changes its derived Signum, - preserve DTD/entity/include relationships, - preserve existing encoding unless migration is explicit, - change the real source file when content comes from an entity/include, - avoid duplicating entity-expanded content directly into the entry XML without a deliberate reason, - preserve unrelated structure and commands, - do not invent unsupported elements, attributes, macros, or Bentley key-ins, - do not treat a runtime-verified example as automatically defining the best style for all new instructions. ## 9. Example evidence vs. canonical rules A working package is strong evidence that MSet can load and execute that package. It is not automatically a recommendation to copy every historical or environment-specific detail into a new instruction. Examples in this knowledge base can be classified as: - `canonical-example` - recommended pattern for new authoring, - `runtime-verified` - known to work, but may contain historical or environment-specific content, - `legacy-example` - historical material for study, - `specialized-example` - product/workflow-specific material. Canonical learning rules take precedence over example style when the two differ. ## 10. What is deliberately not taught yet Do not infer missing behavior from this module. The following require later modules/reference pages: - exact Group-to-Feature command composition, - command separators and normalization details, - `$S`, `$C`, `$X`, - standard ScaleFactor substitutions, - exact scale-sensitive command syntax, - Bentley/MicroStation/OpenRail/OpenRoads key-in catalogues, - Annotation Scale behavior, - MSet control macros such as historical `$M(...)` semantics. In particular, do not generate `$M(...)` for MSet 2026 based only on legacy documentation. ## Completion check Before proceeding to the next Instruction Author module, the model should be able to answer all of these correctly: 1. Is an MSet instruction always only one XML file? **No.** 2. What is the required root element? **`Instruction`.** 3. What native `FormatVersion` is currently supported? **`2026.1`.** 4. What does missing `FormatVersion` mean? **Legacy compatibility mode.** 5. Where does Signum come from? **The entry XML filename without extension, upper-cased.** 6. May an editor ignore DTD/entity/include files? **No.** 7. Should an editor automatically convert CP1250 packages to UTF-8? **No.** 8. Is `Cpt` guaranteed to be a unique technical ID? **No.** 9. Is `Feature` an executable leaf? **Yes.** 10. For a newly authored self-contained single-file native instruction, what is the canonical DTD form? **Embed the current MSet DTD as an internal subset.** 11. Inside a newly authored Group, what child order should normally be used? **Nested Groups first, then direct Features.** 12. Does this module alone make the model a complete MSet Instruction Author? **No.** Next planned module: `02-command-composition.md`. # MSet Instruction Author 02 - Command composition 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 second required module for an LLM that will read, explain, create, or modify an MSet 64-bit instruction. After this module, the model should understand exactly how MSet 2026 builds the source command for a selected `Feature`, how that differs from `Instruction` and `Page` lifecycle commands, how command-fragment boundaries are represented, and how the composition-control macros `$C` and `$X` behave in the current runtime. This module does **not** yet teach standard scale substitution, exact scale-sensitive key-in syntax, Bentley key-in catalogues, or Annotation Scale behavior. `$M(...)` remains outside canonical MSet 2026 authoring guidance. ## Source authority For this module, current MSet 2026 implementation and contract tests are authoritative. The MSet 10 manual and the runtime-verified `MSet_Polohopis` package are supporting evidence where they agree with current behavior. Do not import MSet 32-bit/V8i behavior into this module. ## 1. Three command scopes must stay separate MSet 2026 has three relevant command scopes: 1. `Instruction` direct command text, 2. `Page` direct command text, 3. the effective command of a selected `Feature`. They do not form one inherited chain. ### `Instruction` command Direct command text on the root `Instruction` is a lifecycle command. MSet executes it when that instruction becomes active. It is **not** inherited by a `Feature`. ### `Page` command Direct command text on a `Page` is a lifecycle command. MSet executes it when that Page becomes active, including the initially active first Page when an instruction is activated. It is **not** inherited by a `Feature`. ### `Feature` effective command A selected `Feature` receives command fragments only from: ```text highest ancestor Group -> nested Group(s), in hierarchy order -> selected Feature ``` `Instruction` and `Page` command fragments are deliberately excluded. ## 2. Command fragments are local to their XML node For `Instruction`, `Page`, `Group`, and `Feature`, the parser reads the node's direct text/CDATA as that node's local `CommandFragment`. Text belonging to nested child elements is not automatically merged into the parent's local fragment. DTD/entity expansion happens while the XML document is loaded. Therefore an entity can supply: - command text that becomes part of a local fragment, or - complete XML nodes that become part of the instruction hierarchy. When editing a package, trace entity/include sources before changing what appears to be a local command. ## 3. Canonical Feature composition algorithm For a selected `Feature`, current MSet 2026 composes the source command as follows: 1. walk from the Feature's parent Group toward the root and collect all ancestor Groups, 2. reverse that ancestry so the highest Group comes first, 3. append each non-empty Group `CommandFragment`, 4. append the Feature's non-empty `CommandFragment`, 5. append a semicolon after every contributing fragment. Schematic example. The resource-like names and numeric state values below (for example `Roads`, `co=7`, `wt=2`) are illustrative placeholders only; they are not a resource contract and must not be copied into real authoring without evidence: ```xml co=7 lv=Roads wt=2;place smartline ``` Raw composed source: ```text co=7;lv=Roads;wt=2;place smartline; ``` The order is significant. Do not reorder ancestor Group fragments during an edit unless the intended runtime behavior is also being changed. ## 4. Empty fragments are skipped A `Group` or `Feature` may have an empty/whitespace local command fragment. The composer skips empty fragments. Therefore this is valid: ```xml co=2;wt=1 ``` The Feature has no local command, but its effective source command is still inherited from the Group. Do not automatically delete an empty Feature only because its local command is empty. It may be intentionally executable through inheritance, or intentionally present as UI structure. ## 5. Semicolons: authored separators vs. composition boundaries Inside one local command fragment, authors use `;` to separate individual Bentley/application key-ins. A hand-authored trailing semicolon is not required. Separately, the MSet 2026 composer appends `;` after every contributing Group/Feature fragment. This means the **raw composed source** can temporarily contain repeated semicolons when an authored fragment already ends with `;`. Example: ```text Group fragment: co=7; Feature fragment: place line Raw composition: co=7;;place line; ``` This is not automatically an error. The next processing stage normalizes repeated semicolons. ### Current normalization relevant to composition Before macro processing, MSet normalizes the compound text by: - replacing line breaks/tabs with spaces, - removing whitespace around `;`, - reducing repeated semicolons to one, - reducing repeated whitespace, - trimming the whole string. After later processing, the final compound command is split on `;` into individual dispatch steps. Do not confuse the raw composed source with the final key-ins sent to Bentley. ## 6. `$C` - continue one command across a fragment boundary `$C` suppresses the semicolon that MSet normally inserts immediately after the fragment containing `$C`. Current processing is text-based: 1. composition has already appended the fragment delimiter, 2. normalization has already run, 3. `$C` is removed, 4. if the character immediately after `$C` is `;`, that semicolon is removed too. This joins the current fragment with the next inherited fragment. Example: ```xml place text $C above;Hello ``` Raw composition: ```text place text $C;above;Hello; ``` After `$C` processing: ```text place text above;Hello; ``` The first dispatched key-in can therefore become: ```text place text above ``` ### Important whitespace rule Current MSet 2026 does **not** invent a space when `$C` is removed. If the continued key-in needs a space between the two authored pieces, that space must be present in the text before `$C`, as in: ```text place text $C ``` Do not rewrite it as `place text$C` unless concatenation without a space is intentionally required. ### Runtime-verified real-package pattern `MSet_Polohopis` uses this pattern in Groups such as `Hotové texty`, where a Group starts `place text $C` and the selected child Feature completes the command with text-placement arguments/content. ## 7. `$X` - discard the accumulated command prefix `$X` resets the already composed command prefix. Current MSet 2026 behavior is precise: - macro processing searches the fully composed/normalized string, - the **last** `$X` occurrence wins, - everything before that last `$X` is discarded, - `$X` itself is removed, - leading semicolons remaining after the reset are removed. Example: ```xml lv=Roads;co=2;place smartline $X;edit text ``` Raw composition before macro processing: ```text lv=Roads;co=2;place smartline;$X;edit text; ``` After `$X` processing: ```text edit text; ``` The inherited Group prefix is intentionally gone. ### `$X` can appear in a Group Because `$X` acts on the fully composed text, a Group can reset commands inherited from higher Groups while still allowing its descendant Groups/Features to contribute after the reset. Schematic example: ```xml lv=Outer $X;co=3 place line ``` Result after `$X` processing: ```text co=3;place line; ``` ### Runtime-verified real-package patterns Current `MSet_Polohopis` contains real forms such as: ```text $X;edit text $X;active angle pt2 $Xizolované potrubie ``` The last form is also valid current behavior: `$X` is removed and the following text becomes the retained command/text tail. ## 8. `$C` and `$X` operate after ancestry composition This order matters. Conceptually, the relevant current pipeline is: ```text Group ancestry + Feature | v raw compound source | v Normalize | v Macro processing ($C, $X, and other macros) | v later substitution rules | v split on semicolons | v final dispatch steps ``` Within the current macro rule, `$C` is processed before `$X`. This module teaches `$C` and `$X` only. `$S(...)` and scale-sensitive substitutions belong to the next module. ## 9. Current contract-test evidence: `orná pôda` The runtime-verified `MSet_Polohopis` package contains this structural path: ```text Page "Kreslenie" -> Group "100 Polohopis" -> Group "101 Terénne tvary a kultúry" -> Group "Značky" -> Feature "orná pôda" ``` Relevant fragments are effectively: ```text Group "100 Polohopis": co=bylevel;lc=bylevel;wt=bylevel; Group "101 Terénne tvary a kultúry": lv=101_Terén_a_kultúry Group "Značky": aa=0;place cel rel Feature "orná pôda": ac=3.019_ ``` The current MSet 2026 parser/composer contract test expects the exact **raw effective source command**: ```text co=bylevel;lc=bylevel;wt=bylevel;;lv=101_Terén_a_kultúry;aa=0;place cel rel;ac=3.019_; ``` The doubled `;;` is expected at this raw stage because the first fragment already ends in `;` and the composer appends another boundary delimiter. Normalization later reduces it. The Page command is not present in this effective Feature command. ## 10. Editing rules for command composition When modifying an MSet 2026 instruction: - preserve Group ancestry order, - do not copy `Instruction` or `Page` lifecycle commands into Feature inheritance, - treat each Group/Feature command as a local fragment, - preserve intentional empty fragments, - use `;` between separate key-ins inside one fragment, - do not treat a raw doubled semicolon as proof of an invalid package without considering composition/normalization, - use `$C` only when one logical key-in must continue into a descendant fragment, - preserve the whitespace required around a `$C` continuation, - remember that `$X` discards the entire accumulated prefix before the last `$X`, - trace entities/includes before editing a fragment that may be shared, - do not invent or validate Bentley key-in semantics from composition rules alone. ## 11. What is deliberately not taught yet Do not infer these from this module: - `$S(...)` scale arithmetic, - `Scales` runtime scale-factor calculation beyond structural rules from module 01, - exact current scale-sensitive syntax for cells/text/terminators/line styles, - Bentley/MicroStation/OpenRail/OpenRoads key-in validity, - Annotation Scale behavior, - historical `$M(...)` control-macro semantics as current MSet 2026 authoring guidance. These belong to later modules/reference material. ## Completion check Before proceeding to the next Instruction Author module, the model should be able to answer all of these correctly: 1. Are `Instruction` and `Page` commands inherited into a Feature? **No.** 2. What contributes to a Feature effective command? **Ancestor Groups from highest to nearest, then the Feature.** 3. Are empty local Group/Feature fragments allowed? **Yes.** 4. Does the composer append a delimiter after each contributing fragment? **Yes, `;`.** 5. Can raw composition temporarily contain `;;`? **Yes.** 6. What does `$C` do? **Removes itself and the immediately following composition separator so the command continues into the next fragment.** 7. Does `$C` automatically insert a space? **No.** 8. What does `$X` do? **Discards everything before the last `$X` in the composed command and retains the tail after it.** 9. Can `$X` in a Group reset commands inherited from higher Groups? **Yes.** 10. Does this module prove that an arbitrary Bentley key-in is valid? **No.** Next planned module: `03-scale-and-substitutions.md`. # MSet Instruction Author 03 - Standard scale and substitutions 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 third required module for an LLM that will read, explain, create, or modify an MSet 64-bit instruction. After this module, the model should understand the current **standard numeric MSet scale** model, the runtime meaning of optional ``, the `$S(...)` macro, and the exact scale-sensitive substitution rules currently implemented by MSet 2026. This module deliberately covers **standard scale mode only**. Annotation Scale is not part of this learning module and must not be inferred from it. `$M(...)` also remains outside canonical MSet 2026 authoring guidance. ## Source authority For this module, current MSet 2026 source and contract/runtime tests are authoritative. The MSet 10 manual and the runtime-verified `MSet_Polohopis` package are supporting evidence only where they agree with the current implementation. Current source checkpoint used for reconciliation: MSet 2026 version `26.11.0.4`. Primary implementation evidence: - `MSet.Core/Scaling/ScaleDefinition.cs` - `MSet.Core/Scaling/ScaleState.cs` - `MSet.Core/Scaling/InstructionScaleDefinitionFactory.cs` - `MSet.Core/Instructions/InstructionXmlParser.cs` - `MSet.Core/Substitutions/SubstitutionEngine.cs` - `MSet.Core/Substitutions/SubstitutionContext.cs` - `MSet.Core/Substitutions/Rules/MacroRule.cs` - `TextScaleRule.cs` - `PatternScaleRule.cs` - `CellScaleRule.cs` - `TermScaleRule.cs` - `LineStyleAutoScaleRule.cs` - `MSet.MicroStation/Scaling/MicroStationScaleApplier.cs` Do not import MSet 32-bit/V8i scale behavior into this module. ## 1. Standard MSet scale model The current standard scale model has four important values: ```text PrimaryScale RecommendedScales ScaleFactor <- authoritative runtime value CurrentScale <- derived/displayed drawing scale ``` The defining relationship is: ```text ScaleFactor = CurrentScale / PrimaryScale ``` and, when a stored factor is restored: ```text CurrentScale = round(PrimaryScale * ScaleFactor) ``` Example with `PrimaryScale = 1000`: ```text CurrentScale 1:500 -> ScaleFactor 0.5 CurrentScale 1:1000 -> ScaleFactor 1.0 CurrentScale 1:2000 -> ScaleFactor 2.0 CurrentScale 1:2500 -> ScaleFactor 2.5 ``` `ScaleFactor` is the value used by standard scale substitutions. ### Important authoring consequence `PrimaryScale` is not a decorative label. Changing it changes the relationship between a persisted/runtime `ScaleFactor` and the displayed `CurrentScale`. For the same factor `2.0`: ```text PrimaryScale 1000 -> CurrentScale 2000 PrimaryScale 200 -> CurrentScale 400 ``` Do not change `PrimaryScale` during a routine XML cleanup unless that scale contract is intentionally being changed. ## 2. `` is optional The structural rules from module 01 now have a runtime meaning. A valid custom declaration is for example: ```xml 50,100,200,400,500 ``` Current MSet 2026 rules: - at most one `` element is allowed, - `PrimaryScale` is required when `` is present, - `PrimaryScale` must be a positive integer, - listed scale values are comma-separated positive integers, - `PrimaryScale` must occur in the declared values, - declared value order is preserved, - the list supplies **recommended/quick-pick scales**, not the complete allowed domain. A user may enter any positive integer `CurrentScale`, even when it is not present in `RecommendedScales`. For example, with a default definition, `750`, `1250` or `3000` are valid current scales even if they are not recommended quick picks. ### Missing `` If `` is absent, MSet uses this current default definition: ```text PrimaryScale = 1000 RecommendedScales = 50, 100, 200, 250, 500, 1000, 1440, 2000, 2500, 2880, 5000, 10000, 20000, 25000, 50000, 100000, 200000 ``` The current runtime-verified `MSet_Polohopis` package intentionally contains no `` and therefore uses this default definition. Do not add a `` element merely because it is absent. ## 3. Initial and persisted standard scale A newly created `ScaleState` starts with: ```text ScaleFactor = 1.0 CurrentScale = PrimaryScale ``` For DGN-associated work, MSet restores the persisted standard **ScaleFactor**, not a persisted `CurrentScale` value. Missing, non-positive, non-finite or otherwise unusable persisted factors fall back to `1.0`. The normal Scale dialog lets the user edit a positive integer `CurrentScale`; MSet derives the decimal factor from it. Recommended scales are only quick picks. ### Host-side scale application is not XML authoring When standard scale is applied to MicroStation, the current host adapter sends, in this order: ```text LINESTYLE SET SCALE AS= ``` using invariant decimal formatting. These host-side actions are part of MSet runtime scale application. Do not insert them into an instruction merely to imitate selection of a scale in the MSet UI. ## 4. Where substitutions happen After command composition, the current substitution pipeline runs in this order: ```text Normalize -> MacroRule ($S, $C, $X; $M remains unsupported guidance) -> TextScaleRule -> PatternScaleRule -> CellScaleRule -> TermScaleRule -> LineStyleAutoScaleRule -> split into key-ins -> conservative final optimizer -> dispatch ``` Module 02 remains authoritative for `$C`, `$X`, raw composition and separator normalization. The same substitution engine is used when MSet executes lifecycle command text and Feature commands. However, `Instruction`/`Page` lifecycle scope remains separate from Feature inheritance. ## 5. `$S(number)` - explicit general scale substitution In standard mode: ```text $S(number) -> number * ScaleFactor ``` Example at `ScaleFactor = 2.0`: ```text place cir radius $S(1.5) ``` becomes: ```text place cir radius 3 ``` The command spelling in this example follows the evidence-classified `place cir radius ` form from module 09. This section demonstrates `$S(...)` substitution only; it does not upgrade that parameterized circle form beyond its published historical/supporting evidence state or remove its current-host runtime-test requirement. The current runtime uses invariant numeric parsing for `$S(...)` and strict processing for dispatched commands. Canonical authoring rule: - use a decimal point in `$S(...)`, for example `$S(1.5)`, - do not write locale decimal comma such as `$S(1,5)`, - if the numeric argument is invalid, strict processing fails rather than silently inventing a value. ### Current runtime evidence The MSet 2026 standard-scale path has been runtime-verified end-to-end with a temporary `$S(1)` Feature on MicroStation 2026. The current real `MSet_Polohopis` package also contains `$S(...)` uses such as: ```text ig_svah $S(1000) ... imbo import $S(1) ``` Those package entries prove current `$S(...)` usage. They do **not** make the external `ig_*` or `imbo` key-ins canonical Bentley commands. ## 6. Do not double-scale an automatically scaled parameter `$S(...)` runs **before** the automatic scale-sensitive rules below. Therefore a value can be multiplied twice if an author combines `$S(...)` with a parameter that MSet automatically scales. At `ScaleFactor = 2`: ```text th=$S(2) ``` first becomes: ```text th=4 ``` and then `TextScaleRule` produces: ```text th=8 ``` The same principle applies to other automatically scaled assignments such as `PS=`, `PD=`, explicit `AS=` and explicit `TS=`. **Canonical editing rule:** use `$S(...)` for values that need explicit general scaling, but do not wrap a value in `$S(...)` when that value is already covered by a current automatic scale rule unless double scaling is deliberately intended and verified. ## 7. Text scale substitutions Current `TextScaleRule` recognizes these assignments case-insensitively: ```text tx= th= tw= ls= ``` These are supported scale-sensitive assignment forms, not historical word-prefix abbreviations that should be mechanically expanded. Module 08 defines the canonical-command versus defined-shorthand authoring policy. Their numeric value is multiplied by the current standard `ScaleFactor`. At `ScaleFactor = 2`: ```text th=2;tw=1.5;tx=2.5;ls=0.75;place text ``` becomes: ```text th=4;tw=3;tx=5;ls=1.5;place text ``` In this rule, `ls=` means the text line-spacing parameter. Do not confuse it with line-style selection; line-style selection is handled through `lc=`. The runtime accepts decimal comma in these numeric assignment values and writes scaled values with invariant decimal point. For new canonical authoring, prefer invariant decimal point. ### Real-package evidence `MSet_Polohopis/texty.ent` contains reusable text fragments such as: ```text textstyle active Arial_n;ls=0.75;tx=1.5; ``` These values are intended to pass through the current text scaling rule. ## 8. Pattern scale substitutions Current `PatternScaleRule` recognizes semicolon-delimited tokens beginning with: ```text PS= PD= ``` case-insensitively. Their values are multiplied by standard `ScaleFactor`, and processed output normalizes the key to uppercase `PS=` / `PD=`. At `ScaleFactor = 2`: ```text ps=2;Pd=1.25 ``` becomes: ```text PS=4;PD=2.5 ``` Do not infer additional pattern keys that are not listed here. ## 9. Cell scale substitutions Current cell scaling uses `AS=`. Recognized cell-trigger prefixes are case-insensitive: ```text pla cel place cel ac= ar= cm= ``` Because these are prefix matches, longer forms beginning with them are also recognized. In particular, the full current MicroStation forms `place cell` and `place cell relative` begin with the recognized `place cel` prefix and therefore enter the same MSet cell-scale rule as legacy `pla cel` / `pla cel rel`. For new MSet 2026 authoring, module 08 therefore prefers the full forms `place cell` / `place cell relative`. Legacy spellings remain supported for backward compatibility. ### No explicit `AS=` If the compound command has a cell trigger but no `AS=`, MSet inserts: ```text AS= ``` immediately after the first recognized cell-trigger token. At `ScaleFactor = 2`: ```text place cell relative;ac=TEST ``` becomes at the cell-scale stage: ```text place cell relative;AS=2;ac=TEST ``` ### Explicit `AS=` If an explicit numeric `AS=` already exists, standard mode multiplies that authored value by `ScaleFactor` instead of inserting another scale token. At `ScaleFactor = 2`: ```text AS=1.5;place cell relative ``` becomes: ```text AS=3;place cell relative ``` ### Real-package evidence `MSet_Polohopis` extensively uses inherited cell placement plus `ac=...`, for example a Group with the historically used `place cel rel` spelling and child Features with `ac=`. The current substitution rule supplies standard cell scale for that pattern. Preserve such working historical source when merely analysing it; for newly authored MSet 2026 XML prefer `place cell relative`. ## 10. Terminator scale substitutions Current terminator scaling uses `TS=`. Recognized terminator-trigger prefixes are case-insensitive: ```text pla ter place ter active terminator lt= ``` ### No explicit `TS=` If a terminator trigger is present and no `TS=` exists, MSet inserts: ```text TS= ``` after the first recognized terminator trigger. At `ScaleFactor = 2`: ```text place terminator;lt=ARROW ``` becomes: ```text place terminator;TS=2;lt=ARROW ``` ### Explicit `TS=` An explicit numeric `TS=` is multiplied by standard `ScaleFactor`. Do not infer additional terminator syntax beyond the current recognized prefixes without separate key-in evidence. ## 11. Line-style auto scale Current `LineStyleAutoScaleRule` reacts to a semicolon-delimited token beginning with: ```text lc= ``` case-insensitively. `LC=` is therefore a supported MSet-sensitive assignment form. Do not replace it with a guessed full-word command merely for stylistic normalization; an alternative must be separately verified to trigger the same MSet behavior before it can be treated as equivalent. It inserts: ```text LINESTYLE SET SCALE ``` immediately after that line-style selection unless a nearby line-style scale setter is already present. At `ScaleFactor = 2`: ```text lc=2;place smartline ``` becomes at this substitution stage: ```text lc=2;LINESTYLE SET SCALE 2;place smartline ``` Important current-code details: - `lc=` is the implemented selection trigger; do not broaden this rule to arbitrary `linestyle ...` commands without evidence, - **the trigger applies to `lc=bylevel` as well as numeric/custom selections**, - even when `ScaleFactor = 1`, the current rule may still insert `LINESTYLE SET SCALE 1`, - this rule is distinct from `ls=` text line spacing. ### Runtime evidence - `lc=bylevel` baseline GRAPHICO runtime testing on 2026-08-24 with MSet 2026 `26.11.0.4` confirmed the side effect in Command Inspector. With standard `ScaleFactor = 0.5`, a baseline containing: ```text co=bylevel;lc=bylevel;wt=bylevel;lv=... ``` produced final key-ins including: ```text lc=bylevel LINESTYLE SET SCALE 0.5 ``` Therefore, using `lc=bylevel` for deterministic symbology does **not** mean that standard scale processing is irrelevant. Omitting `` also does not disable the scale model; the default scale definition still applies. Authoring/review must account for this interaction. ## 12. Final optimizer can remove earlier repeated settings After substitution and splitting, current MSet 2026 applies a conservative **last-wins** optimizer only to this explicit whitelist: ```text co= lc= wt= lv= LINESTYLE SET SCALE ``` For each recognized setting category, only its last occurrence survives. Unknown key-ins are not removed or reordered. This matters when Group inheritance contains multiple `lc=` values and the line-style substitution inserts multiple scale setters. Do not use the optimizer as an excuse to generate redundant commands. It is a runtime cleanup step, not a replacement for clear instruction authoring. ## 13. ScaleFactor 1.0 is not a textual no-op Do not assume that `ScaleFactor = 1` means the final command text must be identical to the source. At factor `1.0`: - `$S(x)` resolves to the numeric value `x`, - text numeric values remain numerically unchanged, - pattern keys may be normalized to `PS=` / `PD=`, - a cell trigger without explicit `AS=` may receive `AS=1`, - a terminator trigger without explicit `TS=` may receive `TS=1`, - `lc=` may receive `LINESTYLE SET SCALE 1`. Compare semantics, not only raw string identity. ## 14. Safe authoring rules for standard scale When modifying or generating a standard-scale MSet 2026 instruction: - treat `ScaleFactor` as runtime state, not as a constant stored in the XML instruction, - use `` only to define `PrimaryScale` and recommended quick-pick scales, - do not treat `RecommendedScales` as an allowed-values whitelist, - preserve an existing `PrimaryScale` unless an intentional scale-contract change is requested, - remember that removing `` activates the default `PrimaryScale = 1000` definition, - use `$S(number)` for explicit general numeric scaling, - prefer invariant decimal point in new numeric authoring, - do not double-scale values already covered by automatic rules, - use only the exact automatic scale-sensitive tokens/triggers documented in this module, - do not invent Bentley key-ins merely because MSet can scale their numeric parameters, - distinguish source command, substituted command and optimized final key-ins, - keep Annotation Scale outside this module. ## 15. What is deliberately not taught yet Do not infer these from this module: - Annotation Scale behavior, - historical `$M(...)` control-macro semantics as current MSet 2026 guidance, - validity/meaning of arbitrary Bentley, OpenRail, OpenRoads or external-application key-ins, - complete safe-editing/error-recovery policy for modifying a user's whole package. Those remain separate later knowledge. ## Completion check Before proceeding to the next Instruction Author module, the model should be able to answer all of these correctly: 1. What is the standard scale formula? **`ScaleFactor = CurrentScale / PrimaryScale`.** 2. Are recommended scales the only allowed current scales? **No.** 3. What happens when `` is absent? **Default PrimaryScale 1000 plus the current default recommended list are used.** 4. What is persisted/restored for standard DGN scale state? **ScaleFactor, not displayed CurrentScale.** 5. What does `$S(1.5)` do at factor 2? **It becomes `3`.** 6. Should `$S(...)` normally be nested inside `th=`, `PS=`, explicit `AS=` or explicit `TS=`? **No; those values are automatically scaled and would normally be multiplied again.** 7. Which text assignments are automatically scaled? **`tx=`, `th=`, `tw=`, `ls=`.** 8. Which pattern assignments are automatically scaled? **`PS=`, `PD=`.** 9. What happens to a cell trigger without explicit `AS=`? **MSet inserts `AS=`.** 10. What happens to a terminator trigger without explicit `TS=`? **MSet inserts `TS=`.** 11. What line-style selection token triggers automatic scale insertion? **`lc=`.** 12. Is `ls=` the line-style selector here? **No; it is handled as text line spacing.** 13. Is `ScaleFactor = 1` guaranteed to leave command text unchanged? **No.** 14. Does this module authorize invention of Bentley key-ins? **No.** 15. Does this module teach Annotation Scale? **No.** Next planned module: `04-safe-editing-and-errors.md`. ### CONNECT-safe authoring note The current substitution rules intentionally recognize historical abbreviated triggers such as `pla cel` and `pla ter` for compatibility. For new MSet 2026 authoring, module 08 prefers the established full forms `place cell`, `place cell relative` and `place terminator`. This normalization rule does **not** apply mechanically to compact assignments such as `TH=`, `TX=` or `LC=`: those are supported scale/substitution forms in their own right. Trigger compatibility, defined shorthand and authoring preference are separate concerns. # MSet Instruction Author 04 - Safe editing and error handling 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 fourth required module for an LLM that will read, explain, validate, create, or modify an MSet 64-bit instruction. Modules 01-03 define the package model, command composition, and standard scale/substitution behavior. This module defines the **editing discipline**: how to make a requested change without silently damaging package structure, Signum, encoding, inheritance, scale behavior, or unrelated commands, and how to classify and recover from common failures. Modules 01-04 establish the technical authoring and editing contract. Module 05 adds the required authoring-practice layer. After completing modules 01-05, the Instruction Author track is considered complete for **current MSet 2026 standard-mode instruction authoring**. That readiness has explicit boundaries: it does not certify arbitrary Bentley/application key-ins, Annotation Scale behavior, or historical `$M(...)` control macros. ## Source authority Use the same authority order as the earlier modules: 1. current MSet 2026 runtime/parser behavior and current contract tests, 2. current MSet 2026 specifications and accepted project decisions, 3. current runtime-verified MSet 2026 instruction packages, 4. MSet 10 manual and other legacy documentation. Current source checkpoint used by this track: MSet 2026 version `26.11.0.4`. Relevant current implementation/contract areas include the instruction parser/model, DTD/entity resolution, command composer, substitution engine and runtime-verified `MSet_Polohopis` package. The legacy manual is useful as supporting evidence that XML-aware editing and direct host key-in testing are valid debugging techniques; it does not override current parser/runtime rules. Do not import 32-bit/V8i editing rules into this branch. ## 1. The prime editing rule: change the real source, not the expanded appearance An MSet instruction can be a multi-file XML package. Before changing anything: 1. identify the entry XML, 2. inspect its XML declaration and DTD/entity declarations, 3. follow relevant external entity/include references, 4. locate the file that actually owns the requested content, 5. determine whether that content is reused elsewhere, 6. make the smallest semantic change in that real source file. A command or node visible after XML entity expansion may originate in `.ent` or `.ixml`, not in the entry XML. ### Shared-entity consequence If one entity definition is reused by several nodes, editing the entity changes **every use** of that entity. Before editing a reusable fragment, inspect its references and decide whether the requested change is global or local. For a local-only change, do not casually modify a shared entity. Prefer a deliberate local override/refactor that preserves valid package structure and is checked for all affected references. ## 2. Preserve package identity unless the user asked to change it During an ordinary edit, preserve: - the entry XML filename, - directory layout required by relative references, - DTD/entity/include relationships, - existing file encoding, - `FormatVersion` mode, - unrelated nodes and commands. ### Entry filename and Signum The entry XML filename determines Signum. ```text MSet_Polohopis.xml -> MSET_POLOHOPIS ``` Renaming the entry XML is therefore a semantic change, not cosmetic cleanup. It can break the expected instruction identity/DGN association. Do not rename it unless the requested change intentionally includes a Signum change and the caller understands the consequence. ## 3. Preserve encoding and XML declaration coherently Existing package files may use different historical encodings. The current runtime-verified `MSet_Polohopis` package uses `windows-1250`. Canonical editing rule: - preserve each existing file's encoding during routine editing, - keep the XML encoding declaration consistent with the actual bytes, - do not convert a package to UTF-8 merely because the editor or LLM prefers UTF-8, - perform an encoding migration only when explicitly requested and then validate the complete package. A package that was logically correct before an edit can become unreadable if the file bytes and XML encoding declaration no longer agree. ## 4. Preserve format mode; do not silently migrate legacy instructions Current native format: ```xml FormatVersion="2026.1" ``` Rules: - existing `FormatVersion="2026.1"` -> preserve it unless a deliberate format change is requested, - missing `FormatVersion` -> accepted legacy compatibility mode; do not automatically insert `2026.1` during unrelated cleanup, - unsupported non-empty `FormatVersion` -> do not guess a replacement; report the incompatibility or perform an explicit, reviewed migration. For a newly created modern MSet 2026 instruction, use `FormatVersion="2026.1"`. ### From-scratch native authoring acceptance rules When creating a new MSet 2026 instruction from scratch, apply these acceptance rules: - **a DTD is mandatory**, - if the requested artifact is one self-contained XML file with no support files, embed the DTD as an internal subset, - do not confuse "single file" with "no DTD", - inside each newly authored `Group`, normally place nested Groups before direct Features, - keep the Group's own command fragment before its first child, - establish a deterministic drawing-state baseline at the nearest useful common Group when the descendants depend on active graphical attributes, - use only key-ins with adequate evidence; plausible-looking host commands are not enough. The **Groups-first rule is an authoring convention**, not a parser restriction. The **DTD rule is a product authoring requirement**: do not create or return a DTD-less MSet instruction. A permissive parser accepting some DTD-less XML would not make that XML canonical or valid for MSet authoring. ### Artifact delivery convention The finished instruction/package is delivered as a file artifact, not only as XML pasted into chat: - one self-contained instruction file -> deliver the `.xml` file, - multi-file instruction/package -> deliver a `.zip` that preserves the required relative directory structure, - the attached file/package is the authoritative deliverable; inline text is explanatory/review material. This convention does not change the MSet parser contract. It prevents copy/paste damage to encoding, DTD/entity relationships and package layout, and it scales naturally from one-file examples to entity/include packages. ### Artifact handoff integrity Before reporting an authoring/editing task as finished, verify the **exact artifact that will be returned to the user**, not only a temporary working copy: 1. reopen/read the final `.xml` or the entry XML inside the final `.zip`, 2. verify that the requested semantic change is actually present, 3. verify that unrelated content which should have been preserved is still present, 4. verify that required DTD/entity/include/support-file relationships remain resolvable in the delivered artifact, 5. do not claim completion if the file being attached/returned is an older or original copy that does not contain the requested change. If the tool/client creates several similarly named copies, the artifact selected for delivery must be the one that passed this final verification. A statement such as "done" or "updated" is not sufficient evidence that the returned file is the edited file. ### Continuation after a task-specific re-upload Once the requested task is already established, a newly supplied or re-supplied task-specific XML/package is normally the **current input revision for the same task**. Continue the established task against that newest supplied revision unless: - the user explicitly changes the requested task, - the new file conflicts with the established task in a way that changes the intended result, or - the required target becomes genuinely ambiguous. Do not ask "what should I do with this file?" merely because the user re-uploaded the original/current instruction after an earlier attempt. If the newest supplied revision does not contain the still-requested change, apply that change to the newest revision and then perform the final artifact verification above. ## 5. Structural invariants that an edit must not break The current parser/format contract requires the structural rules taught in module 01. Important checks include: - root element is `Instruction`, - `Page`, `Group`, and `Feature` require `Cpt`, - `Feature` is a leaf and must not gain child instruction nodes, - `Group` may contain nested Group/Feature nodes, - at most one `` element, - when `` exists, `PrimaryScale` and every listed value are positive integers, - `PrimaryScale` must occur in the declared scale list, - every instruction must have a DTD; external DTD/entity/include resources must remain resolvable. Do not edit the DTD merely to make an invented element or attribute appear valid. A DTD change is itself a format-contract change and requires deliberate review. ### Valid things that must not be "cleaned up" as errors These are valid and should not be changed merely for aesthetics: - missing `` (runtime defaults are valid), - missing `FormatVersion` in a legacy-readable instruction, - empty local Group/Feature command fragments, - repeated `Cpt` captions, - entity-based reuse of command fragments or complete node fragments. ## 6. Identify nodes by structural path, not caption alone `Cpt` is display text, not a guaranteed unique technical ID. Bad edit instruction: ```text Change Feature "Hranica parcely". ``` Safer identification: ```text Page "Kreslenie" -> Group "400 Kataster nehnutelnosti" -> Group "402 UO" -> Feature "Hranica parcely" ``` When captions repeat, inspect the surrounding hierarchy and command content before selecting the edit target. ## 7. Preserve command scope while editing Before changing command text, classify where it lives: ```text Instruction command -> instruction lifecycle Page command -> page lifecycle Group command -> inherited Feature prefix/scope Feature command -> selected executable leaf ``` Do not move a command between these scopes merely to make the XML look simpler. Moving text from a Group into one Feature, for example, changes all sibling Features that previously inherited it. For Feature behavior, reason about the complete effective command: ```text highest ancestor Group -> nested Group(s) -> selected Feature ``` Instruction/Page lifecycle commands are not part of that inherited chain. ## 8. Command-editing hazards from modules 02 and 03 A safe editor must preserve these current rules: ### `$C` `$C` suppresses the composition boundary semicolon after its fragment. It does **not** create a joining space. Do not change: ```text place text $C ``` to: ```text place text$C ``` unless concatenation without a space is intentionally required. ### `$X` `$X` discards the accumulated prefix before the **last** `$X`. Adding, deleting, or moving an `$X` can change the whole inherited command, not only the local fragment. ### `$S(...)` `$S(number)` runs before automatic scale-sensitive substitutions. Do not wrap an already automatically scaled assignment (`tx/th/tw/ls`, `PS/PD`, explicit `AS`, explicit `TS`) in `$S(...)` unless deliberate double scaling is required and verified. ### `$M(...)` Historical `$M(...)` semantics are not current canonical MSet 2026 authoring guidance. Do not generate or "repair" `$M(...)` from legacy documentation. ## 9. Key-ins: MSet transport is not proof that a command is valid MSet ultimately dispatches resulting key-ins to the active Bentley host/application. The existence of a string in an instruction does not prove that the host knows it. When authoring or modifying a key-in: - use a documented Bentley/application command, a GRAPHICO runtime-verified command, an existing known-working package command, or explicit user-supplied syntax, - preserve the target product/application context, - do not invent a plausible-looking key-in, - if validity is uncertain, mark it unverified and request/perform host-side verification. Legacy documentation also gives a useful debugging principle: a normal host key-in used by MSet should be testable in the corresponding MicroStation/application command environment. MSet-specific macros/substitutions are the exception because they are processed before dispatch. ## Evidence boundary: unknown means unverified > **Absence of authoritative evidence is not permission to infer syntax.** When a requested action depends on host/application syntax, classify the available evidence before authoring or editing: - **runtime-verified** - exercised successfully on the stated current host/environment, - **runtime-observed** - behavior was observed, but the exact contract may still be narrower than a fully verified general rule, - **historical/supporting evidence** - useful source evidence from older packages/manuals, not automatically current-host proof, - **unverified** - plausible or requested behavior for which the exact command form is not yet established, - **unsupported / known-bad** - explicitly outside the supported contract or known to fail. Do not promote a historical example merely because its syntax looks familiar. If exact syntax is missing, preserve the gap, propose a small host-side runtime test, or simplify the design. In particular, local file/folder launch and configuration-variable expansion remain separately evidence-gated from the runtime-verified HTTP/HTTPS URL action documented in module 10. ## 10. Environment-specific dependencies are not syntax errors A runtime-verified package can contain commands that depend on local configuration or additional applications. The current `MSet_Polohopis` Starter candidate includes examples involving: - `iNGs_Geo` commands, - documentation-path variables, - WMS configuration variables. Do not replace such dependencies with guessed paths or invented commands merely to make the package look self-contained. Instead: 1. identify the dependency, 2. preserve it when the user wants the same environment, 3. remove/replace/guard it only when that behavior is explicitly requested, 4. distinguish "XML/package valid" from "environment dependency available". ## 11. Four validation layers after an edit A safe edit is not complete just because the text looks reasonable. ### Layer A - package integrity Check that: - all expected package files are present, - relative paths still resolve, - edited files retain intended encoding, - the entry filename/Signum relationship is unchanged unless intentional. ### Layer B - XML/DTD/parser validity Check that: - XML is well-formed, - external entities/DTD can be resolved, - DTD validation succeeds when the package uses it, - the instruction has its mandatory DTD (external package DTD or internal subset for a self-contained single file), - root/required attributes/leaf structure are valid, - `FormatVersion` is supported or intentionally legacy, - `` satisfies current parser rules. ### Layer C - MSet semantic transformation For changed commands, evaluate the relevant behavior from modules 02 and 03: - correct Group ancestry and Feature composition, - separator normalization, - `$C` / `$X`, - `$S(...)`, - automatic standard-scale substitutions, - no accidental double scaling. ### Layer D - host/runtime behavior When the change depends on Bentley/application key-ins or external resources, verify it in the intended host/environment when possible. If runtime verification was not performed, say so explicitly. Do not turn "syntactically valid" into "runtime verified" by wording. ### Runtime evidence checkpoint - 2026-08-24 A new self-contained native instruction with `FormatVersion="2026.1"`, an **internal DTD subset**, nested Groups/Features and `` was loaded by MSet `26.11.0.4` in MicroStation 2026. The MSet scale was then changed successfully. Treat this as runtime evidence for the package/DTD/scale acceptance of that tested instruction only. Individual host key-ins in the instruction were not thereby certified. The same benchmark exposed a separate MSet ColorTuner UI crash while clicking the color wheel. It reproduced with the established `MSet_Polohopis` instruction and was therefore unrelated to the generated instruction content. Do not use that UI crash as evidence against instruction syntax or package validity. ## 12. Common error catalogue and recovery ### Error: malformed XML Symptoms: parser cannot load the document, often after unbalanced tags, invalid attribute quoting, or broken entity syntax. Recovery: - compare against the pre-edit file, - fix the smallest XML error first, - do not simultaneously redesign unrelated structure. ### Error: missing or broken external entity/DTD/include Symptoms: package loaded before a move/edit but no longer resolves an external resource. Recovery: - restore the original relative layout or deliberately update all affected references, - verify the referenced file actually exists, - do not flatten the package as a shortcut. ### Error: unsupported `FormatVersion` Symptoms: explicit non-empty version is rejected by current MSet 2026. Recovery: - use `2026.1` for a deliberate native-format instruction, - preserve missing version for legacy mode, - never invent `2026.2`, `2027.1`, etc. without a published runtime contract. ### Error: required `Cpt` removed Symptoms: Page/Group/Feature no longer satisfies current parser/format contract. Recovery: restore a valid caption; do not invent a hidden technical ID as a substitute. ### Error: invalid `` Examples: - multiple `` elements, - non-integer or non-positive values, - non-positive `PrimaryScale`, - `PrimaryScale` absent from the declared list. Recovery: repair the declaration according to module 03, or remove `` only when intentionally choosing the valid runtime default scale definition. ### Error: wrong node edited because captions repeat Recovery: re-identify the node using Page/Group/Feature structural path plus nearby command context. ### Error: shared entity changed unintentionally Recovery: inspect every reference to the changed entity. If only one use should change, restore the shared entity and introduce a deliberate local/source-specific change instead. ### Error: command inheritance changed by "cleanup" Typical causes: - moving a Group fragment into one Feature, - moving Feature text upward into a Group, - moving a lifecycle command into the inheritance tree, - changing ancestor order. Recovery: reconstruct the intended effective command from highest Group to Feature and restore the correct scope. ### Error: `$C` joins tokens incorrectly Recovery: remember that `$C` removes the boundary separator but does not add whitespace. Restore the required authored whitespace. ### Error: unexpected prefix disappears after `$X` Recovery: inspect every `$X` in the fully composed command. The last `$X` wins. ### Error: value is scaled twice Recovery: check whether `$S(...)` was added around a value that is already covered by an automatic scale rule. Remove the redundant explicit scaling unless double scaling is intentional. ### Error: key-in is structurally valid but does nothing in the host Recovery: - do not rewrite XML blindly, - verify the actual key-in in the target Bentley/application environment, - check required external application/configuration/resources, - classify the command as unverified if there is no authoritative evidence. ### Error: characters became corrupted after editing Recovery: - determine the original file encoding, - restore bytes/declaration consistently, - reapply only the intended semantic edit, - validate the whole package again. ## 13. Minimal-change workflow for an LLM For a user-requested modification, follow this sequence: 1. load all four required Instruction Author modules, 2. inspect the complete relevant package, 3. identify the exact target by structural path and real source file, 4. record invariants that must remain unchanged (entry name, encoding, references, FormatVersion, unrelated commands), 5. make the smallest requested semantic change, 6. validate package/XML/parser structure, 7. reason through command composition/substitution if command behavior changed, 8. verify host/environment behavior when required and available, 9. report changed files and any unverified runtime assumptions. Do not combine a requested functional change with unrelated beautification, mass reformatting, encoding migration, renaming, DTD redesign, or legacy-format migration unless the user explicitly requested those changes. ## 14. What `readyForFullAuthoring` means After modules 01-04, the 64-bit Instruction Author track may advertise: ```text readyForFullAuthoring = true ``` This means the model has the complete **core MSet instruction/package authoring contract currently published for MSet 2026 standard mode** and may safely create, review, or modify instructions when it respects the evidence rules below. It does **not** mean: - every Bentley/OpenRail/OpenRoads/OpenSite key-in is known, - every external application command is known, - Annotation Scale is covered, - historical `$M(...)` control macros are supported, - an untested host/environment command may be claimed runtime-verified. Unknown key-ins or environment-specific behavior remain evidence-gated even when the Instruction Author track itself is complete. ## Completion check Before claiming Instruction Author readiness, the model should be able to answer all of these correctly: 1. Must it inspect the complete package before editing? **Yes.** 2. May it silently convert CP1250/XML encoding to UTF-8? **No.** 3. May it rename the entry XML as cosmetic cleanup? **No; that changes Signum.** 4. Should it automatically add `FormatVersion="2026.1"` to a legacy instruction during unrelated cleanup? **No.** 5. Is missing `` an error? **No.** 6. Are repeated `Cpt` captions invalid? **No.** 7. May an empty Feature command be valid? **Yes.** 8. May it edit a shared entity without checking other references? **No.** 9. Does valid XML prove an external Bentley/application key-in works? **No.** 10. What are the four validation layers? **Package integrity; XML/DTD/parser; MSet semantic transformation; host/runtime behavior.** 11. May it claim runtime verification if no runtime test was performed? **No.** 12. Does `readyForFullAuthoring=true` remove the Annotation Scale / `$M(...)` / unknown-key-in boundaries? **No.** # MSet Instruction Author 05 - Good authoring practices 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 fifth required module for an LLM that creates or restructures MSet 64-bit instructions. Modules 01-04 define what is valid and how MSet composes, scales and safely edits commands. This module defines **good authoring habits**: patterns that make instructions deterministic, maintainable and less dependent on whatever graphical state the user happened to leave active before clicking a Feature. This module is intentionally designed to grow. Add a practice only when its MSet behavior and any required Bentley key-ins have adequate evidence. Do not turn plausible MicroStation habits into canonical MSet rules without evidence. ## Authoring philosophy: domain intent first > **MSet translates domain intent into deterministic CAD actions.** For the primary working branches of a newly authored instruction, the default design should be **intent-first**: - `Cpt` names the activity, object or result in the user's/domain vocabulary, - the effective command carries the technical CAD state and tool activation needed to perform that activity, - shared technical setup belongs in the nearest useful ancestor Group, - a descendant Group or Feature may deliberately override only the part that differs. A main working Page built mostly as a palette of `Farba N`, `Hrúbka N`, `Štýl N` and generic geometry buttons can be technically valid, but it is usually a weak MSet authoring default because the user must reconstruct the standard manually. Prefer a Feature that represents the useful work action and lets MSet establish the required state for it. The numeric CAD-state values in the following schematic examples are placeholders used to demonstrate composition. They do not establish a color, line-style or line-weight meaning and must not be copied into a real project without resource/domain evidence. Illustrative inheritance pattern: ```xml co=3;lc=2;wt=5 place smartline place cir ``` Illustrative override pattern: ```xml co=2;lc=4;wt=2 lc=0 place smartline wt=5;place smartline ``` These examples demonstrate **composition and authoring shape**, not a universal mapping from numeric symbology values to visual meanings. Do not claim, for example, that `co=3` means a specific color unless the relevant DGN/workspace/instruction contract or another authoritative source establishes that mapping. ### Color names and the Bentley standard/default color table A user may describe an intended color by name instead of by numeric MicroStation color index. Keep that semantic request separate from the environment-specific `co=` mapping. Use this precedence and lookup discipline: 1. **Load the reference when the question is about the Bentley standard/default table itself.** Questions about its names/aliases, indices, RGB values or `BG` entry should use `reference.standardColorTable` instead of generic model memory. Restricted clients that cannot fetch Markdown use its explicit `text/plain` transport endpoint. 2. **Authoritative project/DGN mapping first for authoring.** If the supplied package, Standards resources or another verified project contract defines color indices, use that mapping. 3. **Explicit applicability confirmation before name -> `co=`.** If no stronger project mapping is available, a human color name may be converted to a numeric `co=` from the Bentley standard table only after the user confirms that the standard/default table applies. 4. **Preserve semantic intent through confirmation.** If the user asked for `zelená` and the assistant asks only whether the standard table applies, a later `áno` confirms that table; the pending color remains `zelená`. Do not silently replace it with another remembered color or earlier example. 5. **Every emitted name -> `co=` is a fresh lookup.** Even for basic colors and even in follow-up turns, explicitly consult the applicable authoritative mapping, resolve the requested name, and cross-check its numeric index against the RGB row before emitting `co=`. Never rely on model memory or a value remembered from an earlier turn. 6. **Otherwise fail closed / ask.** If the active table is unknown, the mapping cannot be consulted, the color wording is ambiguous, or the name/index/RGB cross-check does not agree, do not emit a numeric `co=` value. The standard-table reference contains a deliberately small multilingual alias layer for unambiguous basic colors. After applicability is confirmed, `blue / modrá` resolves to `co=1` (RGB 0,0,255), `green / zelená` to `co=2` (RGB 0,255,0), and `red / červená` to `co=3` (RGB 255,0,0). These three values are useful sanity invariants but do not replace the mandatory per-emission lookup. Always surface the selected numeric index. Do not silently map subjective shades such as `purple/fialová`, `light blue`, `dark green`, `gray/sivá/šedá`, or `black/čierna`; offer candidates or ask for confirmation instead. `MS_DEFCTBL` is not proof that Bentley's published standard RGB table is active: Bentley documents it as the configurable default color-table file used when the DGN has no attached table. A DGN-attached/custom table or project-specific mapping overrides this generic reference. Modifier/state Features remain first-class and useful. A Feature such as `Farba 3`, `Hrúbka 5` or another state-only action is valid when the workflow intentionally exposes a modifier, preset, diagnostic or expert control. The rule is not "every Feature must be a placement tool"; the rule is that **the primary workflow should normally expose the user's intent rather than force the user to assemble low-level CAD state manually**. ### Good pattern / anti-pattern review **Good pattern:** domain-oriented captions; complete useful work actions; shared setup inherited from Groups; narrow intentional overrides; technical modifiers available where they add value. **Anti-pattern:** the main instruction is organized primarily around low-level CAD attributes; the user must select several technical state Features before the real action; captions mirror implementation details instead of the working vocabulary. Technical validity, runtime evidence, authoring quality and domain correctness are separate checks. Domain correctness must come from an expert or an authoritative domain/resource contract; a syntactically perfect instruction can still encode the wrong professional decision. ## 1. Principle: establish a deterministic drawing state A Feature should not accidentally inherit unrelated active graphical attributes from the user's previous tool when those attributes affect the result. Therefore, before the actual placement/edit operation, establish the graphical state that the tool depends on. Typical state categories may include: - active level, - color, - line style, - line weight, - transparency, - priority, - scale-related active settings, - other persistent host attributes relevant to the operation. **Important:** this is a state-hygiene principle, not permission to invent setter key-ins. Only emit concrete setters that are documented, GRAPHICO runtime-verified, present in a verified current package, or explicitly supplied by the user. ## 2. Do not duplicate the same reset in every Feature MSet Group inheritance is the preferred mechanism for a shared drawing-state baseline. Put the baseline in the **nearest common Group** whose descendants need it. Conceptually: ```text Group: safe baseline + common branch setup nested Group: narrower setup or override Feature: only the meaningful local action/delta Feature: only the meaningful local action/delta ``` When a Feature is executed, MSet composes the ancestor Group fragments again. Therefore a baseline written once in a Group is still applied on every descendant Feature execution; it does not need to be copied into every Feature. Prefer: ```text Group baseline -> Group setup -> Feature delta ``` over: ```text Feature A = baseline + setup + action Feature B = baseline + setup + action Feature C = baseline + setup + action ``` This reduces duplication while keeping the runtime command deterministic. ## 3. Baseline, setup, delta For authoring and review, reason about a compound MSet command in three layers: 1. **Baseline / hygiene** - removes unwanted dependence on the previously active graphical state. 2. **Group setup** - establishes the common semantics of the branch, for example a shared level or common graphical attributes. 3. **Feature delta/action** - contains only what is unique to the selected Feature. It may activate a new tool, modify an already-active tool/state, perform another host/application action, or intentionally leave tool selection unchanged. These are conceptual layers. They do not require three XML nodes when a simpler hierarchy is clearer. The goal is deterministic behavior with minimal duplication. ## Output scope: local Feature fragment vs effective command When answering an authoring question, preserve the structural scope the user requested. A local XML node and the effective composed command are related but are **not interchangeable output artifacts**. If the user asks for only a `` snippet, emit the smallest truthful local Feature fragment supported by the established context. Do not automatically: - wrap it in a parent ``, - invent placeholder levels or other resources, - copy inherited Group setup into the Feature, - prepend a tool/placement command such as `place cel rel` merely because that command exists in the effective Group -> Feature execution. For example, if the established branch already supplies cell placement and the requested local hydrant delta is the Point Cell resource, the requested Feature snippet is: ```xml ac=6.120_ ``` Do **not** inflate that local snippet to `place cel rel;ac=6.120_` unless the user asks for a standalone executable Feature or the verified local source/context establishes that placement activation belongs in that Feature itself. Likewise, do not return a synthesized Group when the user asked specifically for the Feature. If the user instead asks for the **effective command**, explain or show the inherited Group contribution separately. If the user asks for a complete standalone instruction/package, then author the complete deterministic structure required by that broader scope. The rule is: **answer at the requested structural scope; add only syntax required at that scope.** This is minimality without losing correctness. ## 4. "Reset" does not always mean numeric zero Do not mechanically set every attribute to `0`. The safe baseline depends on the attribute and on the intended drafting standard. For example, an attribute may need a ByLevel-like state, a numeric zero, a known explicit value, or no reset at all. The exact canonical baseline catalogue will be built incrementally as current MicroStation 2026 key-ins are documented or runtime-verified. Until then: - use only evidenced setters, - reset only state that matters to the descendants, - avoid broad destructive resets that change unrelated user state, - place the reset at the narrowest common Group that gives deterministic behavior. ## 5. Evidence-backed baseline currently available The current runtime-verified `MSet_Polohopis` package provides evidence for using these graphical attribute setters in MSet command fragments: ```text co=bylevel lc=bylevel wt=bylevel ``` They are suitable examples of restoring common symbology attributes to a ByLevel baseline before a branch applies its own overrides. Do not infer unlisted transparency, priority or other setter syntax from these examples. Those entries belong in the future key-in/reference catalogue after verification. ## 6. When should the baseline execute? Default rule: **whenever a Feature whose correctness depends on that state is executed**. In MSet this normally means storing the baseline in the relevant ancestor Group, not manually repeating it at the start of every Feature text. Because Group fragments are recomposed for each descendant Feature selection, the baseline is re-applied each time the compound command is dispatched. Exceptions are possible when: - a state is intentionally user-controlled, - resetting it would be disruptive or destructive, - the Feature does not depend on it, - the required setter is not sufficiently evidenced, - a narrower Group is the correct scope. Do not add resets merely because an attribute exists. Reset state because the tool depends on a known baseline. ## 7. Baseline hygiene does not define what a Feature must do Do **not** infer a hard rule that every Feature must activate a new MicroStation tool or end in a `place ...` key-in. MSet Features can be meaningful in several ways. Depending on context, a Feature may for example: - activate a drawing/editing tool, - change a parameter or mode of a tool that is already active, - set level or graphical attributes, - execute another meaningful host/application command, - open a folder, web page, PDF/documentation or another external resource. The important rule is **semantic consistency**, not mandatory tool selection. A state-only or modifier Feature is valid when its effect is meaningful for its caption and surrounding workflow. If a Feature depends on an already-active tool or state, do not automatically reselect that tool. Instead make sure the dependency is understandable from the Group hierarchy, caption and workflow. Detailed semantic review is required by module 06. ## 8. `lc=` baseline has a standard-scale side effect `lc=bylevel` is evidence-backed as a useful symbology baseline, but it is still an `lc=` token. Module 03 documents that `LineStyleAutoScaleRule` inserts `LINESTYLE SET SCALE ` after `lc=` unless an applicable nearby scale setter already handles it. GRAPHICO runtime verification on 2026-08-24 confirmed this for `lc=bylevel`: at `ScaleFactor=0.5`, Command Inspector showed `LINESTYLE SET SCALE 0.5`. Therefore: - do not claim that scale processing is irrelevant merely because the instruction uses no `$S(...)` and no explicit ``, - when choosing `lc=bylevel` as hygiene, include its line-style-scale side effect in reasoning and runtime review, - do not remove `lc=bylevel` merely to avoid the side effect if deterministic line style is actually required; instead understand and validate the standard scale behavior. ## 9. Review checklist for state hygiene Before accepting a newly authored branch, ask: 1. Which persistent host attributes can change the result? 2. Which of them must be deterministic? 3. Which setters are actually evidenced? 4. What is the nearest common Group for that baseline? 5. Can descendant Features contain only their real differences? 6. Would the baseline unexpectedly modify unrelated user state? 7. Are any claimed transparency/priority/other setters still unverified? If a required setter is unknown, report that gap instead of inventing syntax. ## 10. Baselines must not create invented resource dependencies State hygiene does not authorize selection of a named TextStyle, level, cell or custom line style whose existence is unknown. A deterministic command built on a fabricated resource is not environment-ready. Apply the resource-contract rules from module 07 whenever a baseline/setup references named environment resources. ## Tool-selection preference is separate from evidence status Evidence answers **whether a command form is supported by the knowledge base**. Authoring preference answers **when that supported command is the better choice for a new instruction**. The two classifications are independent. For ordinary new linear drawing, the current GRAPHICO authoring preference is: ```text place smartline -> preferred general-purpose linework place line -> preferred when the intended action is a single line/segment place lstring -> situational; use when LineString element type or that exact workflow is intentional ``` A large instruction should therefore not use `place lstring` as a generic default merely because the command is known. When the requested geometry does not depend on a specific resulting element type, `place smartline` is the preferred general choice. Tool choice remains semantic. If downstream editing, export, standards or application behavior requires a specific element type, that requirement overrides the general preference and must be made explicit in the Feature/context. ## Current boundary This good-practices module establishes the **deterministic drawing state / nearest common Group** pattern and clarifies that state hygiene does not require every Feature to activate a new tool. It does not yet define a complete MicroStation 2026 graphical-state reset catalogue. Transparency, priority and other state categories are explicitly candidates for that future catalogue and remain evidence-gated until their exact key-ins are verified. Module 06 is authoritative for the required semantic/context check between a Feature caption, effective command, hierarchy and workflow assumptions. # MSet Instruction Author 06 - Semantic and context review 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 sixth required module for an LLM that authors or reviews MSet 64-bit instructions. Modules 01-05 establish package structure, command composition, scale processing, safe editing and deterministic-state practices. This module adds the mandatory **Semantic / Context Check**. Syntactically valid XML and valid host key-ins are not enough. An instruction must also make sense as a user workflow. For every Feature, compare what the caption and hierarchy promise with what the complete effective command actually does. ## 1. A Feature is a user action, not necessarily a new tool Do not define `Feature` as "a drawing tool". A Feature may legitimately: - activate a drawing or editing tool, - change a parameter/mode of the tool that is already active, - set level, symbology or other persistent state, - execute another meaningful Bentley/application action, - open a folder, web page, PDF/documentation or another external resource, - perform another purposeful action supported by an evidenced command. Therefore there is **no canonical rule that every Feature must contain `place ...` or activate a new tool**. Re-selecting a tool can even be wrong when a Feature is intended only to modify the currently active tool. ## Intent-first workflow check The Semantic / Context Check also reviews the **shape of the workflow**, not only each leaf in isolation. For a primary working branch, ask whether the user can select the meaningful professional action directly, with MSet composing the required technical state behind it. A collection of honest state-only Features is not invalid. However, if the main workflow requires the user to assemble color, weight, style and tool selections manually before doing routine work, review whether those settings should instead be inherited and combined into intent-oriented Features. Keep modifier/state Features when they are deliberately useful as presets, expert controls or adjustments. This authoring-quality rule does not authorize invented domain captions or resource meanings. The domain vocabulary and any claimed visual meaning of numeric CAD attributes still require authoritative evidence. ## 2. Mandatory Semantic / Context Check For every newly authored or materially changed Feature, review these four things together: 1. **`Cpt` promise** - what does the caption reasonably tell the user will happen? 2. **Effective command** - what does the complete highest-Group -> nested-Group(s) -> Feature command actually do after composition/substitution? 3. **Parent context** - does that effect make sense inside the surrounding Group hierarchy? 4. **State/tool assumptions** - does the Feature rely on a tool or state already being active, and is that dependency understandable in this workflow? Acceptance question: > **Does this Feature do what its `Cpt` and surrounding Group context reasonably promise to the user?** If the answer is unclear, redesign the caption, hierarchy or command. Do not hide the mismatch in a postscript. ## 3. Tool Feature and modifier/state Feature are both valid Example conceptual workflow: ```text Group: Text Feature: Place text -> activates the text placement tool Group: Alignment Feature: Left -> changes alignment only; text tool remains active Feature: Center -> changes alignment only; text tool remains active Feature: Right -> changes alignment only; text tool remains active ``` The three alignment Features are not incomplete merely because they do not activate the text tool again. Their meaning comes from the surrounding Text/Alignment context and the expected active-tool state. The exact alignment key-ins are **not** defined by this example. They remain evidence-gated until present in canonical key-in knowledge, a verified package, runtime evidence, or explicit user input. ## 4. Preset/state Features are valid when honestly presented A Feature that only sets state can be useful. For example, an effective command might establish ByLevel symbology and activate a known level while leaving the current drawing tool unchanged. That is semantically valid when the user-facing caption/context communicates a preset/state action, such as conceptually: ```text Set symbology - wooden fence ``` It is potentially misleading if the same state-only command is presented as a complete operation such as conceptually: ```text Wooden fence - line ``` when a reasonable user would expect the Feature itself to start drawing that line. The problem is not the absence of `place ...`; the problem is the mismatch between **promise and effect**. ## 5. Active-tool/state dependencies must be contextual, not accidental A modifier Feature may deliberately depend on previously selected state. Review whether the dependency is stable and understandable: - Is the Feature grouped under the tool/workflow it modifies? - Is the caption clear enough to signal a modifier/preset rather than a standalone operation? - Is the required preceding state naturally established by a sibling/ancestor workflow? - Would selecting this Feature from an unrelated current state produce a surprising result? Do not automatically reset or reselect everything. Preserve intentional continuity when continuity is the point of the Feature. ## 6. External-resource Features are first-class actions A Feature may open documentation or another resource rather than modify graphics. This can include a folder, web page, PDF or another supported external target. For such Features: - the caption should describe the resource/action, - the command/path/URL mechanism must be evidenced for the target environment, - environment variables and file paths must be treated as dependencies, - do not apply irrelevant graphical baselines merely because module 05 discusses drawing-state hygiene. ## 7. Evidence discipline still applies Semantic correctness and key-in validity are separate checks. A command may be meaningful but unsupported. A command may be valid but semantically wrong in context. Both dimensions must pass. For each host/application command: - use canonical/reference evidence, a verified current package, GRAPHICO runtime evidence, or explicit user-supplied syntax, - do not use web plausibility or model memory as a substitute for MSet.AI evidence when the task is explicitly constrained to the Hub, - if a required command is not evidenced, simplify the design or report the gap rather than silently invent syntax. Do not solve an evidence gap by producing a semantically misleading Feature. ## 8. Environment dependencies are part of semantic review A Feature can be syntactically and semantically well designed while still depending on environment resources such as: - level names, - text styles, - cell libraries/cells, - custom line styles/resources, - configuration variables, - external files/folders/URLs, - application-specific commands. Identify these dependencies explicitly. Do not claim the instruction is environment-ready merely because the XML and command composition are valid. ## 9. Review procedure for every Feature For each Feature in a from-scratch instruction or substantial redesign: 1. Resolve its structural path. 2. Compose its full effective Group -> Feature command. 3. Apply relevant MSet substitutions/optimizer reasoning from modules 02-03. 4. State the real user-visible effect. 5. Compare that effect with `Cpt` and parent Group context. 6. Identify any active-tool/state assumptions. 7. Identify environment/resource dependencies. 8. Verify evidence for every host/application key-in used. 9. If promise, effect and context do not agree, redesign before presenting the instruction as finished. ## 10. From-scratch authoring acceptance Before returning a newly authored instruction, the LLM must be able to say: - every Feature has a purposeful effect, - no Feature is required to activate a new tool merely by rule, - modifier/state Features intentionally preserve the relevant active tool/state when appropriate, - captions and hierarchy honestly communicate what the Features do, - graphical baselines are applied only where relevant, - scale side effects (including `lc=` line-style auto scale) have been considered, - host key-ins are evidence-backed, - environment dependencies are distinguished from MSet syntax/semantics, - remaining runtime assumptions are explicit. ## 11. Named-resource check Semantic review must include a resource-contract check. A command such as `textstyle active `, `lv=` or a cell/custom-line-style selection can be syntactically meaningful while still being unusable because the named resource does not exist. For finished authoring, use named resources only when they are known to exist or are explicitly declared to be provisioned. Do not invent plausible names and call them merely "environment dependencies" after the fact. Module 07 is authoritative for resource states, TextStyle use and explicit-text fallback patterns. ## Geometry-specific semantic contract: resulting element type For geometry Features, semantic review includes one additional question when downstream behavior depends on it: ```text Does the resulting MicroStation element type matter for the intended workflow? ``` If the answer is no, a general-purpose tool may be preferred. If the answer is yes, the selected placement command must intentionally produce the required geometry/element workflow and the reason should be visible in the Feature caption, Group context, resource contract, or review notes. This prevents a command from being chosen only because it is syntactically valid. For example, `place lstring` is not the default substitute for general linework when `place smartline` better matches the user action and no LineString-specific requirement exists. ## Current boundary This module defines semantic/context review. It does not provide a complete MicroStation 2026 key-in catalogue and does not authorize invention of alignment commands, external-launch commands, drawing tools or other host syntax merely because their intended action is semantically clear. Annotation Scale and historical `$M(...)` remain outside the current Instruction Author track. # 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. # MSet Instruction Author 08 - CONNECT-safe key-in forms 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 Historical V8/V8i instructions are valuable evidence, but their abbreviated MicroStation key-ins are not automatically the best syntax for new CONNECT/Open authoring. The central rule is: > **For new MSet 2026 instructions, prefer the full canonical MicroStation command form when the current evidence establishes it. Preserve supported defined shorthands/assignment forms when they are themselves part of the command contract or MSet scale/substitution contract. Historical prefix abbreviations are legacy evidence, not the default authoring style.** This distinction is important because a short form is not automatically a bad abbreviation. ## 1. Three different kinds of key-in form ### A. Full canonical command Examples established by current MicroStation runtime reconstruction include: ```text PLACE CELL PLACE CELL RELATIVE PLACE TERMINATOR ACTIVE ANGLE PT2 REFERENCE DISPLAY TOGGLE ``` For new MSet 2026 authoring, prefer these full forms when they express the intended operation. ### B. Supported defined shorthand / assignment form MSet 2026 intentionally recognizes several compact assignment forms as part of its current scale/substitution behavior. Examples include: ```text TH= TW= TX= LS= PS= PD= AS= TS= LC= AC= AR= CM= LT= ``` Do **not** mechanically expand these merely because they are short. For example, `TH=`, `TW=`, `TX=` and `LS=` are explicit inputs to the current `TextScaleRule`; `LC=` is the implemented trigger for line-style auto-scale; `AC=`, `AR=` and `CM=` participate in cell-scale detection; and `LT=` participates in terminator-scale detection. Module 03 owns the exact substitution behavior. A compact assignment form that is part of a verified MSet runtime contract is different from an old prefix abbreviation of a word command. ### C. Historical prefix abbreviation Examples from historical MSet material include: ```text pla ... act ... ``` These spellings remain valid historical evidence and may remain supported for backward compatibility, but they are not the preferred default for newly authored MSet 2026 XML when a full canonical form is established. ## 2. Cell placement: canonical form is preferred and MSet-scale-safe Current MicroStation 2026 runtime reconstruction establishes: ```text PLACE CELL PLACE CELL RELATIVE ``` Current MSet 2026 source independently establishes that the cell scale rule recognizes both the legacy and full-command families case-insensitively through prefixes including: ```text pla cel place cel ``` Because `place cell` and `place cell relative` begin with the recognized `place cel` prefix, they enter the same `CellScaleRule` as legacy forms such as `pla cel` / `pla cel rel`. Therefore, for new MSet 2026 authoring prefer: ```text place cell place cell relative ``` Historical forms such as: ```text pla cel pla cel rel place cel rel ``` must not be treated as errors when analysing or preserving an existing instruction. Do not rewrite an old package only for cosmetic modernization unless the user is intentionally migrating/editing it. ### Authoring consequence This is an important correction to old MSet guidance: the current MSet 2026 scale/substitution implementation no longer requires the historical `pla cel` spelling in order to apply cell scale behavior. Full `place cell` / `place cell relative` forms are recognized by the same current rule. ## 3. Terminator placement: canonical form is preferred and MSet-scale-safe Current MicroStation 2026 runtime reconstruction establishes: ```text PLACE TERMINATOR ``` Current MSet 2026 source recognizes terminator triggers including both: ```text pla ter place ter ``` through case-insensitive prefix matching. Therefore full: ```text place terminator ``` enters the same current terminator scale logic as historical `pla ter`. For new MSet 2026 authoring prefer `place terminator`; preserve historical spelling when analysing or maintaining old source unless a migration is requested. ## 4. Known leading-token normalization Where only the leading historical verb is being normalized, these mappings remain valid: ```text pla ... -> place ... act ... -> active ... ``` Example: ```text act ang pt2 -> active angle pt2 ``` However, do not stop at a half-expanded form when the complete current canonical command is independently established. For example, for cell placement prefer: ```text place cell relative ``` rather than merely: ```text place cel rel ``` because the current runtime command table establishes `PLACE CELL RELATIVE` and current MSet cell-scale recognition is compatible with it. ## 5. Do not invent expansions This module does not authorize expanding arbitrary abbreviations by English guesswork. Only normalize a short form when the modern form is established by current runtime reconstruction, Bentley evidence, explicit MSet runtime evidence, or another authoritative current source. Examples of what **not** to do: - do not assume every three-letter V8i token has one unique CONNECT expansion, - do not expand a defined assignment such as `TX=` merely because a longer English phrase exists, - do not replace `LC=` with a guessed word command and assume MSet line-style auto-scale will still fire, - do not infer that a historical prefix pair is a general alias rule for every command family. If an exact modern form is unresolved, preserve the historical spelling as evidence and mark the modern form as unresolved rather than inventing one. ## 6. Runtime compatibility versus authoring preference Keep these questions separate: 1. **What exact key-in does the current MicroStation host expose/accept?** 2. **What exact spelling does MSet 2026 recognize for its own substitution/scale behavior?** 3. **What spelling should be preferred for new MSet 2026 authoring?** They often agree, but they are not the same evidence question. Examples now established: | Operation | Historical form | Preferred new form | Current MSet substitution consequence | | --- | --- | --- | --- | | cell placement | `pla cel` | `place cell` | same current cell-scale rule | | relative cell placement | `pla cel rel` | `place cell relative` | same current cell-scale rule | | terminator placement | `pla ter` | `place terminator` | same current terminator-scale rule | | angle by two points | `act ang pt2` | `active angle pt2` | authoring normalization; not a scale trigger | A legacy form being supported does not make it the preferred spelling for new XML. Conversely, a short assignment being compact does not make it legacy or undesirable. ## 7. Interaction with text authoring and scale-sensitive assignments Historical GRAPHICO text examples can remain evidence for structure, parameters and workflow, but leading word-command abbreviations should use established full forms in new MSet 2026 XML. Historical source: ```xml pla note;ft=23;th=1.5;tw=1.5;active txj cc ``` New-authoring form: ```xml place note;ft=23;th=1.5;tw=1.5;active txj cc ``` Notice that `th=` and `tw=` remain compact. They are supported assignment forms and are intentionally processed by MSet; they are not rewritten merely to make every token longer. The same rule applies to `tx=`, `ls=` and the other scale-sensitive assignments documented by module 03. ## 8. Review checklist Before accepting a newly authored or modernized MSet 2026 command, ask: 1. Is there an established full current MicroStation command for the requested operation? 2. If yes, am I using that full form for a new instruction? 3. Is the short form actually a supported defined shorthand/assignment that should remain compact? 4. Does MSet attach special scale/substitution behavior to the exact form I am changing? 5. If this is an old package, am I preserving working historical syntax unless migration was requested? 6. Am I avoiding guessed expansions whose current mapping is not established? 7. Am I keeping MicroStation command validity separate from MSet-specific substitution recognition? ## Current boundary This module defines the authoring policy and publishes the cell/terminator equivalence that is now supported by both current MicroStation command reconstruction and current MSet 2026 substitution-source evidence. It is **not** a complete V8i-to-CONNECT migration catalogue. Add further canonical mappings only when their exact current form is evidenced. In particular, do not claim a canonical replacement for `LC=`, `AC=`, `AR=`, `CM=`, `LT=` or other defined assignments merely by expanding their letters; their current MSet-sensitive behavior is authoritative until a verified equivalent is deliberately added. # MSet Instruction Author 09 - Basic geometry and placement patterns 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 module adds a small, evidence-classified vocabulary for **primitive geometry and placement workflows**. Its purpose is to let a new instruction contain useful line/circle/shape operations without turning historical material into unqualified MicroStation 2026 truth. The evidence model is explicit: - current MSet composition/substitution rules remain canonical, - GRAPHICO historical instructions are supporting host-key-in evidence, - GRAPHICO current-host tests may promote an exact key-in or variant to runtime evidence without promoting unrelated commands, - module 08 supplies only the CONNECT-safe normalizations that are actually established, - a historical geometry key-in remains **runtime-test-required** on the current host until stronger evidence exists. This module does not create a complete MicroStation key-in catalogue. ## 1. Evidence-backed primitive geometry vocabulary The following table combines historical GRAPHICO instruction evidence with exact current-host observations that GRAPHICO has separately runtime-tested. | Operation | Historical source spelling | Canonical new-authoring spelling | Evidence state | | --- | --- | --- | --- | | simple line | `pla line` | `place line` | historical real-instruction evidence; current-host runtime test still required | | line string | `pla lstring` / full-form examples also exist in later source material | `place lstring` | historical/supporting evidence; current-host runtime test still required | | smart line | `pla smartline` and some full `place smartline` examples | `place smartline` | historical/supporting evidence; current-host runtime test still required | | rotated block | - | `place block rotated` | **GRAPHICO runtime-verified on MicroStation 2026, 2026-08-26** | | interactive circle | - | `place cir` | **GRAPHICO runtime-verified on MicroStation 2026, 2026-08-26**; radius is chosen interactively rather than supplied as a numeric key-in parameter | | circle by edge | - | `place cir edge` | **GRAPHICO runtime-observed on MicroStation 2026, 2026-08-26**; invokes the three-point/circumference method, not the desired interactive-radius workflow | | circle by radius | `pla cir radius ` | `place cir radius ` | historical real-instruction evidence; current-host runtime test still required for the parameterized form | | shape | `pla shape` | `place shape` | historical real-instruction evidence; current-host runtime test still required | Evidence examples include: ```text Georeal_GP.xml: pla line Georeal_GP.xml: pla lstring Georeal_GP.xml: pla cir radius $S(2) Georeal_PO.xml: pla shape DTM_TP historical material: place smartline / pla smartline ``` Module 08 changes only the established leading command abbreviation: ```text pla -> place ``` It does **not** authorize arbitrary expansion of later tokens. ## 1A. Authoring preference for line tools Command evidence and authoring preference are tracked separately. | Canonical form | Evidence state in this module | Authoring preference | | --- | --- | --- | | `place smartline` | historical/supporting; current-host runtime test still required | **preferred-general** for ordinary new multi-segment/general linework | | `place line` | historical real-instruction; current-host runtime test still required | **preferred-single-segment** when the action is specifically one line/segment | | `place lstring` | historical/supporting; current-host runtime test still required | **situational-element-type** when LineString output or that exact workflow is intentional | | `place shape` | historical real-instruction; current-host runtime test still required | **situational-closed-area** when a Shape/closed-area workflow is intended | | `place block rotated` | current-host runtime-verified | **block-specific** when a rotated block/rectangle workflow is intended | | `place cir` | current-host runtime-verified | **preferred-interactive-circle** when the radius is to be chosen interactively | | `place cir edge` | current-host runtime-observed as three-point/circumference placement | **three-point-circle-only**; do not use as a substitute for the interactive-radius workflow | | `place cir radius ...` | historical real-instruction; current-host runtime test still required for the parameterized form | **explicit-radius-circle** when a numeric/scaled radius value is intentionally supplied | The default for general linear CAD authoring is therefore `place smartline`, not mass use of `place lstring`. `place lstring` remains valid evidence-backed syntax, but its use should follow an explicit LineString/workflow reason rather than habit. ## 2. Circle spelling and variant boundary Historical circle evidence uses: ```text pla cir radius $S(2) ``` For new MSet 2026 authoring, the established normalization of that evidenced parameterized form is therefore: ```text place cir radius $S(2) ``` The token `cir` must not be silently rewritten to `circle`. Current GRAPHICO runtime evidence now independently confirms that `cir` is also used by the working MicroStation 2026 variants below. Module 08 still forbids guessing unknown expansions. ### Runtime-verified interactive circle GRAPHICO runtime test on MicroStation 2026 (2026-08-26) verified: ```text place cir ``` as the desired interactive circle-placement workflow in which the radius is chosen interactively in the host rather than supplied as a numeric key-in parameter. ### Runtime-observed variants that are not substitutes The same test session observed: ```text place cir edge ``` invoking the three-point/circumference circle method. It is therefore not a substitute when the requested workflow is the interactive-radius `place cir` behavior. The session also observed that invoking the `radius` variant **without supplying a new numeric radius value** reused the previous radius. Do not choose that incomplete form when the user asks to pick a new radius interactively. The historically evidenced parameterized form `place cir radius ` remains separately classified and should not be conflated with the no-value observation. These are variant-specific observations. They do not certify untested circle subcommands or authorize inventing other `place cir ...` forms. ## 3. Primitive geometry can be resource-independent A primitive line or circle need not depend on a named level, cell, TextStyle or custom line style. A small geometry branch can therefore be authored without inventing environment resources. Example structure: ```xml co=bylevel;lc=bylevel;wt=bylevel place smartline place line place cir radius $S(2) ``` This is an authoring pattern, not a claim that all three host operations have already been runtime-verified on MicroStation 2026. Their evidence state must remain visible in review/output until current runtime verification promotes them. ## 4. Tool placement may be local or inherited The same semantic rule from modules 02 and 06 applies to geometry: - a geometry Feature may contain its placement tool locally, - or an ancestor Group may carry the tool while descendant Features provide only meaningful deltas. Historical GRAPHICO instructions contain patterns such as a `pla lstring`/`place lstring` Group with child Features that select line style/weight/color variants. A child Feature is complete in context when its **effective command** contains the intended drawing tool through Group ancestry. ## 5. Geometry captions must match the effective command For a Feature presented as a concrete drawing operation, semantic review compares the caption with the complete effective command. Examples: - `Cpt="Jednoduchá čiara"` is consistent when the effective command activates `place line` locally or through ancestry. - `Cpt="Kružnica r=2"` is consistent when the effective command contains the evidenced circle-radius operation. - a state-only command such as `co=bylevel;wt=bylevel` is not a complete line/circle operation unless the caption/context clearly presents it as a preset or modifier. This is **not** a rule that every Feature must activate a tool. It is the module-06 promise/effect/context rule applied to geometry. ## 6. Geometry baseline placement Primitive geometry commonly depends on active graphical attributes. When deterministic symbology is required, an evidenced baseline such as: ```text co=bylevel;lc=bylevel;wt=bylevel ``` belongs in the nearest common geometry Group that actually needs it. The baseline is not automatically global. A text, measurement, external-document or unrelated action branch should not inherit line-style state merely because a geometry branch needs it. Because `lc=` is a current MSet line-style scale trigger, `lc=bylevel` can produce: ```text LINESTYLE SET SCALE ``` That side effect remains part of the final-command review. ## 7. Circle radius and MSet scale The historical GRAPHICO geometry pattern includes: ```text place cir radius $S(2) ``` Current MSet 2026 module-03 semantics establish `$S(number)` as explicit standard-scale substitution. Circle `radius` is not one of the automatic `tx/th/tw/ls`, `PS/PD`, cell-scale or terminator-scale assignments. Therefore `$S(...)` is an appropriate scale mechanism for a radius value when a scale-sensitive circle is intended and the host command itself is accepted by the target runtime. Do not place `$S(...)` around assignments already handled automatically by module 03 unless deliberate double scaling is intended. ## 8. `dialogtext above/below` is element-relative GRAPHICO clarification for the text patterns in module 07: ```text place dialogtext above place dialogtext below ``` represent placement **above/below an element**, not generically above/below a point. Canonical captions/context should therefore use wording such as: ```text Poloha k elementu Nad elementom Pod elementom ``` A caption such as `Nad bodom` / `Pod bodom` is semantically misleading for this evidenced operation and fails the module-06 context check. ## 9. Evidence labels for new geometry authoring A generated instruction/review should keep these categories distinct: ```text MSet-canonical behavior composition, macros, scale/substitution, DTD/package rules GRAPHICO historical/supporting host evidence place line place lstring place smartline place cir radius ... place shape Current-host runtime evidence place block rotated (MicroStation 2026, GRAPHICO, 2026-08-26) place cir (MicroStation 2026, GRAPHICO, 2026-08-26) place cir edge (runtime-observed three-point/circumference variant, 2026-08-26) other operations only after the exact operation has been exercised on the target runtime ``` Historical evidence is sufficient to make a geometry operation a legitimate **candidate** in a benchmark or draft that explicitly calls for runtime verification. It is not sufficient to label the operation `runtime-verified MicroStation 2026`. ## 10. Geometry authoring review checklist For a geometry branch, the review covers: 1. the effective command contains the intended tool locally or through ancestry, 2. `Cpt` describes what the effective command really does, 3. baseline attributes are placed only in the geometry scope that needs them, 4. `lc=` scale side effects are understood, 5. no named level/custom line style/cell is invented, 6. any `$S(...)` use is not double-scaled by another MSet rule, 7. historical host-key-in evidence is not mislabelled as current runtime verification, 8. CONNECT-safe normalization uses only mappings actually established by module 08, 9. `place smartline` is preferred for general linework unless a single-segment or specific element-type requirement justifies another tool, 10. circle variants are selected by their verified behavior: `place cir` for the current interactive-radius workflow, `place cir edge` only for the observed three-point/circumference method, and an explicit `place cir radius ` only when a supplied radius is intended. ## Current boundary This module deliberately keeps a **small evidence-classified geometry vocabulary**. `place block rotated` and `place cir` are now current-host runtime-verified, and `place cir edge` has a specific runtime-observed three-point behavior. This does not certify every MicroStation drawing tool, construct command, constraint, arc/ellipse operation, custom line style, circle variant or application-specific placement command. Those items belong in the future evidence-classified key-in reference and are promoted individually after documentation/runtime verification. # MSet Instruction Author 10 - Instruction appearance and external utility links Status: **canonical-development** Branch: **MSet 64-bit** Current product: **MSet 2026 by GRAPHICO** Format covered: **MSet 2026 native instruction format 2026.1** ## Purpose This module defines two user-facing authoring capabilities that are part of the current MSet 2026 workflow: - optional per-instruction UI colors, - external web links presented as explicit utility Features. Both capabilities are presentation/workflow concerns. They do not change Feature command composition and they do not change `FormatVersion="2026.1"`. ## 1. Optional Instruction color scheme The current `Instruction` root supports these optional attributes: ```text TextColor BackgroundColor ``` Canonical authoring uses six-digit RGB hex: ```xml ``` The corresponding current DTD declaration is: ```dtd ``` These attributes are optional UI metadata. They are not Bentley named resources and do not set MicroStation element colors. A native instruction with or without them remains format `2026.1`. When valid Instruction colors are present, MSet applies them for that instruction in preference to the per-user appearance fallback. If they are absent, normal user/default appearance remains available. ## 2. Color choice is part of instruction UX A generated instruction may define its own recognizable color pair when the authoring task allows it. The pair should remain readable and should not imitate CAD element symbology semantics. A useful authoring review records the chosen pair explicitly: ```text Instruction appearance TextColor: #203040 BackgroundColor: #E9F2F8 ``` MSet's appearance tool can copy the currently tuned pair in XML-attribute form, so hand-edited and visually tuned instructions use the same representation. ## 3. Runtime-verified external URL action On 2026-08-24, MSet `26.11.0.4` in MicroStation 2026 runtime-tested this exact Final Key-in: ```text $ % "https://www.graphico.sk/mset/ai/" ``` Result: the URL opened successfully in the system/default web browser. Evidence state for the URL-launch pattern is therefore: ```text $ % "https://..." MSet 2026 / MicroStation 2026: runtime-verified by GRAPHICO ``` Historical MSet_Polohopis instructions also contain the same pattern for ZBGIS, CICA, SKPOS, Google Maps, FreeMap, Mapy.cz and product/documentation links. The current runtime test promotes the **URL-launch mechanism**, not every historical URL. ## 4. External links belong on a utility Page For new authoring, web links are normally separated from drawing tools on their own Page. This is a GRAPHICO UX best practice, not a DTD restriction. Example structure: ```xml $ % "https://www.graphico.sk/mset/ai/" $ % "https://zbgis.skgeodesy.sk/mkzbgis/sk/kataster" ``` This keeps the primary CAD Page focused on geometry/text/state workflows and makes external navigation discoverable without mixing it with placement commands. A Page caption such as `Odkazy a pomôcky`, `Web a pomôcky`, or another domain-appropriate equivalent is suitable when it accurately describes the content. ## 5. URL/resource discipline The launch mechanism may be runtime-verified while the destination itself is still an external dependency. The review therefore distinguishes: ```text mechanism evidence: runtime-verified URL destination: explicit/known external dependency ``` A URL supplied by the user, present in a verified package, or otherwise explicitly established for the task is suitable. Internal/private destinations should not be invented. Public destinations chosen by the author should be identifiable and relevant to the instruction purpose. If a URL contains XML-reserved characters such as `&`, XML element text must preserve well-formedness, for example by using `&`. ## Local file, folder and configuration-variable launch boundary The current authoring contract does **not** generalize the verified HTTP/HTTPS form to local targets. Historical packages provide supporting evidence that local documents/folders and environment/configuration variables have been used, but the exact current MSet 2026 behavior still needs targeted runtime verification for: - a local folder path, - a local document/PDF path, - paths containing spaces and their quoting, - a real published Bentley/MSet/Windows configuration variable, - a missing target/error path. Suitable runtime-test candidates include, for example: ```text $ % "C:\Temp" $ % "C:\Temp\Test.pdf" ``` These strings are **test candidates, not canonical production authoring syntax**. Until the exact cases pass current-host runtime tests, report the documentation gap instead of generating a local-launch command by analogy with the verified URL mechanism. ## 6. External actions are valid Feature semantics A Feature is a user action, not necessarily a drawing-tool activation. An external-link Feature therefore passes the same module-06 Semantic / Context Check when: - `Cpt` names the destination/action clearly, - the effective command is the intended `$ % "URL"` launch action, - the parent Group/Page presents it as a utility/link rather than CAD geometry, - no unrelated graphical-state dependency is implied. Graphical baselines such as `co=`, `lc=` or `wt=` do not belong above a link-only Page merely by habit. ## 7. Recommended page separation A compact multi-purpose instruction commonly benefits from this top-level separation: ```text Page: Kreslenie geometry / text / modifiers Page: Odkazy a pomôcky maps / standards / product help / project web resources ``` The second Page is optional. It is recommended when the instruction contains several external links or documents. ## 8. Review checklist For appearance and external utilities, review: 1. `TextColor` and `BackgroundColor` are optional and use canonical `#RRGGBB` form when present, 2. the DTD declares both optional attributes when the XML uses them, 3. `FormatVersion` remains `2026.1`, 4. foreground/background are reasonably readable together, 5. web actions use the runtime-verified `$ % "URL"` pattern, 6. link Features live in a utility-oriented Page/Group rather than being mixed randomly into drawing branches, 7. destination URLs are explicit dependencies and are not fabricated private resources, 8. XML-reserved URL characters are escaped correctly, 9. external-link branches do not inherit irrelevant geometry baseline state. ## Current boundary The current runtime evidence proves opening an HTTP/HTTPS URL through `$ % "..."`. Historical packages also use the same mechanism for local documents and folders, but those path/variable cases retain their own evidence status until separately current-runtime verified. This module does not promote all historical file/folder launch patterns merely because URL launch succeeded. # MSet 2026 key-in evidence reference - MicroStation Status: **canonical-development evidence index** Branch: **MSet 64-bit** Target: **MSet 2026 / MicroStation 2026 unless a row says otherwise** Release: **20260919-v35** Knowledge version: **2026.09.19-v35** ## Purpose This is a compact evidence reference for MSet-relevant MicroStation command forms and promoted semantics. It combines reviewed Instruction Author evidence with current runtime reconstruction, real MSet corpus observations, Bentley documentation/support evidence and explicitly labelled GRAPHICO production practice. If an operation is not present here or in another authoritative current source, treat its exact syntax as unverified. ## Evidence labels - **runtime-verified** - exercised successfully by GRAPHICO on the stated current host/runtime. - **runtime-observed** - a specific behavior was observed; do not generalize beyond that observation. - **historical/supporting** - established by historical GRAPHICO packages/manual evidence and suitable as a candidate where the task explicitly allows verification, but not current-host proof. - **canonical normalization/rule** - an MSet authoring rule about a known form; it does not prove arbitrary commands that merely resemble it. - **unverified** - no exact current authoritative command contract yet. - **Bentley-documented** - semantics/syntax supported by Bentley Help/Support material; keep the cited scope/version in mind. - **runtime-reconstructed** - canonical syntax reconstructed from the current MicroStation runtime command table; this proves the command surface, not every semantic detail. - **corpus-observed** - observed in real historical/production MSet instruction packages; occurrence is practice evidence, not by itself semantic authority. - **GRAPHICO production-practice** - empirical recommendation from long-term MSet/MicroStation production use; keep it distinct from Bentley documentation. - **MSet-runtime-contract** - behavior established by current MSet 2026 source for MSet-specific composition/substitution; this is separate from proof that MicroStation itself accepts an arbitrary spelling. - **Bentley-documented** - semantics/syntax supported by Bentley Help/Support material; keep the cited scope/version in mind. - **runtime-reconstructed** - canonical syntax reconstructed from the current MicroStation runtime command table; this proves the command surface, not every semantic detail. - **corpus-observed** - observed in real historical/production MSet instruction packages; occurrence is practice evidence, not by itself semantic authority. - **GRAPHICO production-practice** - empirical recommendation from long-term MSet/MicroStation production use; keep it distinct from Bentley documentation. ## Current command index | Command/form | Evidence | Scope / authoring note | Canonical source | | --- | --- | --- | --- | | `co=bylevel` | runtime-verified package evidence | Evidence-backed symbology baseline used by the current verified `MSet_Polohopis` package. | module 05 | | `lc=bylevel` | runtime-verified package evidence | Evidence-backed baseline; remember MSet line-style auto-scale processing after `lc=`. | modules 03, 05 | | `wt=bylevel` | runtime-verified package evidence | Evidence-backed symbology baseline. | module 05 | | `place smartline` | historical/supporting; current-host runtime test still required; current authoring preference | Preferred general-purpose linework when no specific resulting element type is required. | modules 05, 09 | | `place line` | historical/supporting; current-host runtime test still required | Single-line/segment-oriented candidate. | module 09 | | `place lstring` | historical/supporting; corpus-observed; GRAPHICO production-practice | Situational when LineString/exact workflow intent matters; not the generic default. In 3D prefer `place smartline` unless LineString identity is required: GRAPHICO has empirically observed occasional incorrect `place lstring` behavior in 3D. | modules 05, 09 + production practice | | `place shape` | historical/supporting; current-host runtime test still required | Geometry candidate; not labelled current-host runtime-verified by the track. | module 09 | | `place cir radius ` | historical/supporting; parameterized form current-host runtime test still required | Explicit-radius circle candidate; `$S(...)` may be appropriate for a scale-sensitive numeric radius when requested. | module 09 | | `place block rotated` | runtime-verified | GRAPHICO MicroStation 2026 runtime verification, 2026-08-26. | module 09 | | `place cir` | runtime-verified | Current interactive-radius circle workflow; GRAPHICO MicroStation 2026 runtime verification, 2026-08-26. | module 09 | | `place cir edge` | runtime-observed | Observed three-point/circumference variant on 2026-08-26; do not substitute it for the interactive-radius workflow. | module 09 | | `place dialogtext above` / `place dialogtext below` | historical/supporting semantic evidence | The evidenced relation is above/below an **element**, not generically above/below a point. | modules 07, 09 | | `PLACE CELL` | runtime-reconstructed; MSet-runtime-contract | Full current command surface. Preferred for new MSet 2026 authoring; current MSet `CellScaleRule` recognizes it through the case-insensitive `place cel` prefix, so it gets the same MSet cell-scale handling as legacy `pla cel`. | MicroStation 2026 runtime reconstruction + modules 03, 08 | | `PLACE CELL RELATIVE` | runtime-reconstructed; MSet-runtime-contract | Preferred full form for new relative-cell placement. Current MSet cell-scale recognition is equivalent to legacy `pla cel rel`. | MicroStation 2026 runtime reconstruction + modules 03, 08 | | `PLACE TERMINATOR` | runtime-reconstructed; MSet-runtime-contract | Preferred full form for new terminator placement. Current MSet terminator-scale rule recognizes it through the case-insensitive `place ter` prefix, equivalent to legacy `pla ter` for MSet scale handling. | MicroStation 2026 runtime reconstruction + modules 03, 08 | | `TH=` / `TW=` / `TX=` / `LS=` | MSet-runtime-contract | Supported text scale-sensitive assignment forms. Keep them compact; do not mechanically expand them as if they were legacy word-prefix abbreviations. | module 03 | | `LC=` | MSet-runtime-contract | Current trigger for MSet line-style auto-scale. Do not substitute a guessed full-word spelling unless equivalent MSet behavior is separately verified. | module 03 | | `AC=` / `AR=` / `CM=` | MSet-runtime-contract | Current cell-related triggers used by MSet cell-scale detection. Their own values are not the scale value; the cell rule ensures/adjusts `AS=`. | module 03 | | `LT=` | MSet-runtime-contract | Current terminator-related trigger used by MSet terminator-scale detection; the terminator rule ensures/adjusts `TS=`. | module 03 | | historical `pla ...` -> new-authoring `place ...` | canonical normalization/rule | Prefer a complete established canonical command when available, not merely a half-expanded leading token. Example: `pla cel rel` -> `place cell relative`. | module 08 | | historical `act ...` -> new-authoring `active ...` | canonical normalization/rule | Normalize the known leading token; do not guess unrelated unknown abbreviations. Example: `act ang pt2` -> `active angle pt2`. | module 08 | | `ACTIVE FILLCOLOR` | corpus-observed; historical/supporting | Sets the active fill color. | MSet corpus + Bentley/supporting key-in evidence | | `ACTIVE TXJ ` | corpus-observed; Bentley/supporting semantic evidence | Sets Text justification. Use the justification suffix table below. | MSet corpus + Bentley support/archive evidence | | `ACTIVE TNJ ` | corpus-observed; Bentley/supporting semantic evidence | Sets Text Node justification. Use the same justification suffix table below. | MSet corpus + Bentley support/archive evidence | | `FILEDESIGN` | corpus-observed; Bentley-documented/supporting | Save Settings for the active design file; useful at the end of batch/reference display command sequences when the change must persist. | MSet corpus + Bentley support | | `SELVIEW ` | corpus-observed; Bentley-documented/supporting | Supplies the target view (or all views) to view-specific command sequences such as reference-level display operations. | MSet corpus + Bentley support/archive | | `LOCK FENCE INSIDE` / `LOCK FENCE CLIP` | corpus-observed; Bentley-documented/supporting | Sets Fence Selection Mode to Inside / Clip. | MSet corpus + Bentley support/archive | | `REFERENCE EXCHANGE` | corpus-observed; direct Help semantic evidence | Opens/exchanges to the selected reference as the active working model while retaining the view configuration. See DGN reference section below. | MSet corpus + Bentley Help/training | | `RASTER ATTACH FIXED` | runtime-reconstructed; Bentley-documented/supporting | Attaches a raster without interactive placement; use the raster/header attachment geometry unless another placement contract is specified. | MicroStation 2026 runtime + Bentley support | | `RASTER DETACH ALL` | runtime-reconstructed | Canonical current-runtime command surface for detaching all raster attachments. | MicroStation 2026 runtime reconstruction | | `USERCOMMAND` | corpus-observed; legacy/supporting | Legacy MicroStation User Command / UCM invocation mechanism. Do not infer modern parameters or a current recommended workflow from the bare command name. | MSet corpus + historical MicroStation evidence | ## Text and Text Node justification For natural-language authoring, map the requested justification to the suffix first, then choose Text (`TXJ`) or Text Node (`TNJ`). The justification point is the text/text-node anchor (reference point). | Suffix | Meaning | Slovak intent examples | | --- | --- | --- | | `LB` | Left Bottom | vľavo dole | | `LC` | Left Center | vľavo na stred | | `LT` | Left Top | vľavo hore | | `CB` | Center Bottom | na stred dole | | `CC` | Center | na stred / stred | | `CT` | Center Top | na stred hore | | `RB` | Right Bottom | vpravo dole | | `RC` | Right Center | vpravo na stred | | `RT` | Right Top | vpravo hore | Examples: ```text "zarovnaj text vpravo hore" -> ACTIVE TXJ RT "zarovnaj text-node vľavo dole" -> ACTIVE TNJ LB ``` Do not confuse Text with Text Node: use `TXJ` for ordinary text and `TNJ` for a text node. ## DGN / vector reference operations This is the semantic/reference section for working with attached DGN/vector references. Prefer a stable **logical name** when a project provides one; it is usually more robust for automation than a physical path/file name. Configuration-variable/relative reference paths are preferable to hard-coded machine-specific paths where the project contract supports them. ### Display, levels and view targeting - `REFERENCE DISPLAY ON|OFF|TOGGLE ` controls the whole reference attachment display. Nested references may be addressed as paths such as `Ref_1.dgn->Ref_2.dgn`; `*`/`ALL` may be used where Bentley documents wildcard use. - `REFERENCE LEVELS ON|OFF|TOGGLE ` controls **View Display** of levels in a reference. This is view-specific; follow it with `SELVIEW ` or `SELVIEW ALL` when the command sequence must explicitly target views. - `LEVEL SET DISPLAY ON|OFF file: ` controls **Global Display**, including reference levels. Do not present this as a synonym for `REFERENCE LEVELS`: View Display and Global Display are different states. - `FILEDESIGN` saves design settings. In batch/reference workflows it is commonly appended after the view-selection command when the display state must persist. Example patterns documented by Bentley support/archive material: ```text REFERENCE LEVELS OFF Preliminary REF->ISO;SELVIEW ALL;FILEDESIGN LEVEL SET DISPLAY OFF file:"testV08.dgn" Preliminary;SELVIEW ALL;FILEDESIGN ``` ### Attachment settings and nested references Bentley documents a general `REFERENCE SET` family. Useful settings include: ```text REFERENCE SET DISPLAY=ON|OFF REFERENCE SET SNAP=ON|OFF REFERENCE SET LOCATE=ON|OFF REFERENCE SET DISPLAYRASTERREFS=ON|OFF ``` `file_spec` may be a file name or logical name; nested paths may use `->`. Keep exact task-specific selectors evidence-gated rather than guessing them. ### Attach / detach / exchange Bentley documents the full attach family as: ```text REFERENCE ATTACH [configuration_variable:]filename [,model_name] [,logical_name] [,description] [,view_name] [,scale] [,nesting] [,ON|OFF] ``` Supplying enough arguments can avoid the interactive dialog. Project configuration variables and relative/reference-root paths are preferred when they are part of the project contract. `REFERENCE DETACH` is a current canonical runtime command and is heavily observed in the MSet corpus; do not guess an attachment-selector tail when it is not already established by source/task context. `REFERENCE EXCHANGE` changes the selected reference into the active working model and retains the same view configuration. Historical/practical evidence describes the operation as swapping the reference and active/master roles. GRAPHICO production experience further observes that the new active model opens at the same working location/zoom seen immediately before the exchange; keep that exact location/zoom statement labelled **GRAPHICO production-practice** rather than Bentley-documented semantics. ## Raster references Raster attachments are managed separately from DGN/vector references. Raster Manager changes attachment information in the DGN; it does not modify the original raster image data. ### Attach ```text RASTER ATTACH FIXED RASTER ATTACH INTERACTIVE ``` - **Interactive** placement lets the user define the raster extents/placement with data points. - **Fixed** is the non-interactive attachment path; unlike interactive placement, it does not ask the user to define raster extents with placement data points. Use the established attachment/file geometry and project georeferencing contract rather than inventing placement coordinates. - Historical V8i command-line batch processing may require `MDL LOAD RASTMGR` before `RASTER ATTACH FIXED`; this is legacy/supporting evidence, not a blanket MicroStation 2026 prerequisite. ### Display, clipping and detach ```text RASTER DISPLAY ON RASTER TOOLCLIP RASTER DETACH ALL ``` `RASTER DISPLAY ON` is Bentley-documented for raster display; `RASTER TOOLCLIP` is Bentley-documented as the raster clipping tool key-in; `RASTER DETACH ALL` is reconstructed from the current MicroStation 2026 runtime command table. ### Rasters carried through DGN references When the raster is attached **inside a DGN reference**, use the DGN-reference setting rather than treating it as a direct master-model raster attachment: ```text REFERENCE SET DISPLAYRASTERREFS=ON|OFF ``` This controls whether raster references belonging to the specified DGN reference are displayed. Keep this distinction explicit: ```text "vypni raster pripojený priamo v tomto modeli" -> RASTER ... "vypni rastre, ktoré prichádzajú cez referenciu PODKLAD" -> REFERENCE SET DISPLAYRASTERREFS=OFF PODKLAD ``` ## Provenance boundary for the promoted semantic sections The semantic additions above combine several evidence layers and must keep them distinct: - MicroStation 2026 runtime reconstruction: canonical command surface/existence. - Real MSet corpus: historical/production occurrence and frequency. - Bentley Help/Support/archive material: documented/supporting semantics and command patterns. - GRAPHICO production-practice: empirical recommendations such as preferring `PLACE SMARTLINE` over `PLACE LSTRING` in 3D when exact LineString identity is not required, and the observed exact working-location/zoom continuity of `REFERENCE EXCHANGE`. Do not promote a corpus occurrence or an empirical recommendation into a Bentley-documented claim. ## MSet-mediated external action The following is not a general Bentley drawing key-in entry, but it is part of the current MSet authoring evidence contract: ```text $ % "https://..." ``` Evidence: **runtime-verified** in MSet `26.11.0.4` / MicroStation 2026 for HTTP/HTTPS URL opening. See module 10. Do **not** infer from that result that these are canonical yet: ```text $ % "C:\Temp" $ % "C:\Temp\Test.pdf" $ % "" ``` Local folder/document launch, variable expansion, path quoting and missing-target behavior remain **unverified** until their exact current-runtime tests pass. ## Boundary This reference is deliberately small. It is an evidence index, not a complete MicroStation key-in manual. A missing entry must remain a documentation/runtime gap unless another authoritative current source or explicit user-supplied syntax establishes it.