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