# MSet 2026 / 64-bit Project Environment transport bundle releaseId: `20260919-v35` knowledgeVersion: `2026.09.19-v35` branch: `64` track: `project-environment` bundleSchemaVersion: `2026.1` canonicalManifest: `https://www.graphico.sk/mset/ai/releases/20260919-v35/64/manifest.json` requiredPublishedModulesCount: `5` sourceCount: `5` payloadUtf8Bytes: `17140` payloadSha256: `568722902C6B2AE6C28DA1E6A84FBA745CD20A4D83AA5B17B39F0D3B2124FA4E` completionMarker: `` This file is a deterministic on-demand transport artifact for AI clients that cannot retrieve the published Project Environment Markdown modules. It contains the LF-normalized UTF-8 text of every project-environment.requiredPublishedModules document in immutable-manifest order. This is supporting project-environment knowledge; do not preload it for unrelated MSet instruction authoring. 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.project-environment.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. # Project Environment 01 - Configuration model and scope Status: **published / supporting knowledge** Branch: **MSet 2026 / 64-bit Bentley CONNECT/Open generation** ## Purpose This track helps an AI reason about the MicroStation project environment around MSet. It is intentionally lighter than a full Bentley administration reference. Load it when a task materially concerns: - Configuration / Custom Configuration, - WorkSpace or WorkSet, - project/environment `.cfg` files, - Standards/resource ownership or search order, - environment diagnostics, - shared/network deployment, - or V8i Project/PCF migration. For ordinary MSet XML authoring, keep using the Instruction Author track without loading this domain. ## 1. Core CONNECT/Open model A useful conceptual hierarchy is: ```text Configuration -> WorkSpace -> WorkSet -> DGN / project data ``` MicroStation configuration processing also has levels such as Organization, WorkSpace, WorkSet, Role and User. Those levels help determine where configuration statements are applied. Do not confuse configuration level with guaranteed resource priority. Effective resource selection can also depend on the variable being used, assignment operators, final search/list order, locks and resource-family behavior. ## 2. Default layout is a convention, not a prison A typical environment keeps reusable standards at WorkSpace level and project-specific material at WorkSet level, but physical roots are redirectable. Do not force every customer into one folder tree. A valid design may keep: - managed/shared Standards centrally, - project data on another drive/share, - WorkSet-specific overrides near project data, - product-owned MSet resources outside the customer tree. The important question is **who owns each resource and how MicroStation resolves it**, not whether every file sits under one parent folder. ## 3. MicroStation 2026 guided configuration UI MicroStation 2026 provides guided UI for creating/managing Configurations, WorkSpaces and WorkSets. Treat that as a useful authoring/administration workflow, not as a replacement for understanding the resulting `.cfg`, variables and resource paths. When troubleshooting or reviewing an AI-generated environment, the resolved configuration remains the evidence that matters. ## 4. Production boundary Keep customer/company production configuration out of Bentley-delivered program content. Prefer Custom Configuration and supported user/admin touch points. If a workflow would require editing product-owned/generated configuration files directly, treat that as an administrator/deployment action and verify it against the target MicroStation version before recommending it. ## 5. Interaction rule For a greenfield request, do not start with a long questionnaire. Ask only for the smallest missing input that blocks the next useful step. Good first questions are usually about the intended project family or whether the environment is reusable across multiple related WorkSets. # Project Environment 02 - Greenfield WorkSpace and WorkSet Status: **published / supporting knowledge** ## Purpose This module covers a common MSet-facing request: > Create a standalone MicroStation CONNECT/Open WorkSpace with a first WorkSet and a new MSet instruction. It gives a practical design sequence, not a universal directory template. ## 1. Decide the family boundary first Use a **WorkSpace** for standards/configuration intended to be shared by a family of related projects or WorkSets. Use a **WorkSet** for one concrete project/job and its project-specific data or overrides. If the request is really one isolated project with no expected family reuse, keep the structure simple; do not invent a large corporate hierarchy just because MicroStation supports one. ## 2. Establish identities and roots Choose clear names for: - Configuration, when a separate Custom Configuration is needed, - WorkSpace, - first WorkSet, - project-data root, - shared Standards root. Then create/review the corresponding `.cfg` and folder structure using the customer's intended deployment topology. MicroStation 2026 guided configuration UI may be used where appropriate. It is an **alternative workflow**, not a prerequisite. If the user asks for a reproducible standard local package, AI may generate the minimal `.cfg` files directly; do not refuse solely because no existing `.cfg` was supplied. ### Standard local greenfield pattern For the ordinary local/default topology, the WorkSpace `.cfg` is a sibling of the WorkSpace directory, and the WorkSet `.cfg` is a sibling of the WorkSet directory inside `WorkSets`: ```text /WorkSpaces/ |-- Elektrorozvod_Obec_WorkSpace.cfg `-- Elektrorozvod_Obec_WorkSpace/ |-- Standards/ | `-- MSet/ | `-- MSet_ElektroObec.xml `-- WorkSets/ |-- Obec_Ukazka.cfg `-- Obec_Ukazka/ `-- dgn/ ``` MicroStation may also create/manage the WorkSet `.dgnws` beside the WorkSet `.cfg`. Do not synthesize a `.dgnws` as a hand-written text file merely to make the package look complete. A concise WorkSpace `.cfg` candidate for this standard layout is: ```text _USTN_WORKSPACEROOT = $(_USTN_WORKSPACESROOT)$(_USTN_WORKSPACENAME)/ _USTN_WORKSPACESTANDARDS = $(_USTN_WORKSPACEROOT)Standards/ _USTN_WORKSETSROOT = $(_USTN_WORKSPACEROOT)WorkSets/ MSET_INSTR_DIR = $(_USTN_WORKSPACEROOT)Standards/MSet/ ``` A concise WorkSet `.cfg` candidate is: ```text _USTN_WORKSETROOT = $(_USTN_WORKSETSROOT)$(_USTN_WORKSETNAME)/ _USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)$(_USTN_WORKSETSTANDARDSDIRNAME)/ _USTN_WORKSETDGNS = $(_USTN_WORKSETROOT)$(_USTN_WORKSETDGNSDIRNAME)/ ``` These lines make the standard layout explicit and reviewable. MicroStation has defaults for the same normal topology, so a generated package does not need unrelated configuration merely to appear sophisticated. Do not add legacy `MS_DGNAPPS > mset` to a customer WorkSpace: MSet 2026 runtime discovery/autoload belongs to the installed MSetup/product binding. For redirected roots, shared/network deployment, ProjectWise, administrator locks, or other non-standard topology, stop treating this skeleton as deployment-ready and inspect the actual environment contract. ## 3. Classify resources by ownership Before placing resources, classify them: - reusable across related WorkSets -> usually WorkSpace/shared Standards, - specific to one project -> usually WorkSet/project scope, - supplied by MSet installation -> MSet product scope, - Bentley-delivered defaults -> host product scope. Examples include DGNLIBs, cell libraries, seeds, fonts, custom line styles and MSet instruction packages. Do not create fake resource names merely to make the tree look complete. ## 4. New MSet instruction When the environment also needs a new MSet instruction: 1. establish where the instruction package will live, 2. establish how `MSET_INSTR_DIR` or the applicable MSet discovery configuration will resolve it, 3. use the Instruction Author track for the XML/package itself, 4. keep project-environment decisions separate from XML authoring decisions. A useful shared pattern is a WorkSpace-level `Standards\MSet\` location when related WorkSets intentionally share the same instruction. In the standard local pattern above, `MSET_INSTR_DIR = $(_USTN_WORKSPACEROOT)Standards/MSet/` intentionally points MSet at that shared instruction directory. If an existing corporate configuration intentionally uses several instruction roots or a different discovery policy, inspect the resolved value instead of blindly replacing that policy with this example. ## 5. Output expectation A useful AI result may include: - proposed folder/layout sketch, - `.cfg` files or snippets, - resource ownership table, - MSet instruction package, - short validation checklist. When the user explicitly asks to **create** a standard local WorkSpace with its first WorkSet, do not return only a folder named `...WorkSpace` plus a README. Include the discoverable WorkSpace `.cfg`, the WorkSet `.cfg`, and the matching directory structure, while clearly separating generated configuration from runtime verification. Do not claim runtime success until the environment is tested in the target MicroStation/MSet installation. # Project Environment 03 - Resources and MSet integration Status: **published / supporting knowledge** ## 1. Resource precedence: design intent versus actual resolution A useful MSet design intent is often: ```text project/WorkSet-specific resources -> shared WorkSpace/customer resources -> MSet Starter Standards -> Bentley/default resources ``` But do **not** present this as an automatic MicroStation law. The effective resource may also depend on: - the configuration variable used, - `=`, `:`, `<`, `>`, `+` assignment behavior, - final expanded search/list order, - `%lock` or administrator constraints, - resource-specific variables, - duplicate-name behavior of the resource family. Therefore say: **implement and verify the intended priority**. ## 2. Resource families are not identical Common environment resources include: - DGNLIBs, - cell libraries, - seed files, - fonts, - custom line-style resource files, - reference-file search paths. When troubleshooting, inspect the variable relevant to the missing resource family. Do not assume that one generic path explains every resource type. For DGNLIB-backed content, resource-specific `MS_DGNLIBLIST_*` variables may matter in addition to generic `MS_DGNLIBLIST`. ## 3. MSet product boundary MSet runtime discovery/autoload belongs to MSet/MSetup product installation. A customer WorkSpace should not recreate a legacy `MS_DGNAPPS > mset` dependency merely to launch MSet 2026. Customer or corporate configuration may intentionally provide a different `MSET_INSTR_DIR` for instruction discovery. MSet Starter Standards are additive product-provided resources when enabled. They should not prevent a deliberately configured customer WorkSpace/WorkSet resource from taking precedence. ## 4. Two independent associations Keep these separate: 1. Bentley DGN-to-WorkSet association, 2. MSet DGN instruction/signum association, including the MSet instruction identity and Scale-related state. Passing one does not prove the other. ## 5. Troubleshooting rule When a resource appears missing or the wrong same-name resource is used: 1. identify the resource family, 2. identify the relevant configuration variable(s), 3. inspect the resolved list/order, 4. inspect WorkSpace/WorkSet/customer/MSet ownership, 5. verify in runtime. Do not solve a search-order problem by blindly copying duplicate resources into more folders. # Project Environment 04 - Validation and deployment boundaries Status: **published / supporting knowledge** ## 1. Validate in layers Keep project-environment validation separate from MSet instruction validation. A useful sequence is: ```text STATIC files, cfg, folders, declared resources CONFIGURATION RUNTIME selected Configuration / WorkSpace / WorkSet resolved variables and search paths BENTLEY RUNTIME DGN opens in intended context required resources are available WorkSet association is correct where required MSET RUNTIME MSet loads through product binding instruction is discovered representative Features execute correctly ``` A static package can be correct while runtime resolution is wrong. Report those states separately. ## 2. Diagnostics Useful evidence can include: - MicroStation configuration debug output, - resolved configuration variables, - `_USTN_DISPLAYALLCFGVARS=1` when hidden framework variables must be inspected, - reproducible WorkSpace/WorkSet selection at startup, - actual runtime resource availability. Do not infer resolved configuration only from the text of one `.cfg` file. ## 3. UI and administrator policy If a user cannot create/select a WorkSpace or WorkSet in the UI, consider administrator policy/configuration restrictions before concluding that the capability is absent. ## 4. Shared/network configurations Shared or network Configurations are normal CONNECT/Open deployment patterns. Keep read-mostly managed Standards separate from high-churn/user-specific state where practical, and validate network paths/performance in the actual environment. ## 5. ProjectWise boundary ProjectWise Managed WorkSpace is a separate deployment layer. Do not treat it as merely replacing local paths with ProjectWise paths. Baseline rule: > first prove the ordinary WorkSpace/WorkSet locally or in its normal configuration context; then adapt it to ProjectWise and revalidate. Load ProjectWise-specific knowledge only when the task actually concerns ProjectWise deployment. ## 6. DGNWS / DGNSI boundary For most MSet project-environment tasks, keep this simple: - DGNWS remains WorkSet/project metadata state, - MicroStation 2026 uses DGNSI for the newer Sheet Index workflow, - legacy DGNWS-based Sheet Index details are mainly a migration/version topic. Do not load deeper Sheet Index knowledge unless the task needs it. # Project Environment 05 - Migration and reference case Status: **published / supporting knowledge** ## 1. Migration is a scenario, not the whole domain Use this module when converting an older MicroStation V8i Project/PCF environment into CONNECT/Open-generation Configuration / WorkSpace / WorkSet form. Do not mechanically translate every legacy variable. First recover the intent: - which resources were shared, - which data was project-specific, - which application-loading rules are obsolete, - which paths represent standards versus live project data, - which dependencies still exist in the target generation. ## 2. Faithful first, modernization second For a production migration: 1. reproduce the old environment's intended behavior as faithfully as practical, 2. make only compatibility-required repairs, 3. validate runtime, 4. modernize structure/naming/workflows in a separate pass. This keeps migration defects separate from optional cleanup. ## 3. Canonical Polohopis case The GRAPHICO Polohopis case is the current runtime-proven reference migration: - historical V8i project/environment and MSet instruction were reconstructed as a CONNECT/Open WorkSpace with a `Demo` WorkSet, - reusable cells, DGNLIB, seed and instruction package were classified as WorkSpace-level shared standards for that project family, - MSet Starter Standards replaced selected legacy shared symbol resources, - MSet product binding remained product-owned rather than recreated in the customer WorkSpace, - Bentley WorkSet association and MSet signum/instruction association were validated separately, - selected legacy abbreviated word key-ins required CONNECT-safe canonicalization, - the migration was runtime-tested on MicroStation 2026 with MSet 2026 and accepted as faithful migration v2 PASS. These are reference-case decisions, not universal folder/resource rules for every customer. ## 4. Migration output A useful migration result should distinguish: - preserved behavior, - compatibility repairs, - dropped obsolete settings, - deferred dependencies/replacements, - runtime verification still required, - optional modernization ideas.