13be0ef90f
Eleven commits from the sister site: a reversible Maximo/WINC machine-adoption import, a versioned agent binary store with upload and rollback, remote-BuildKit CI, tray version reporting, and UI fixes. Applied as a patch again - the published mirror rewrites hashes, so the branches have unrelated histories and git refuses to merge them. Reviewed by three agents before merging. Four things fixed here. THE PUBLISH WORKFLOW WAS DEAD. The new remote-BuildKit step in publish-images.yml sits at column 0 instead of indented under steps:, so the whole file is invalid YAML and GitHub would refuse it. Their entire GHCR distribution channel - which Start-ShopDBDev.ps1 and the compose files consume - was broken at the source and clearly never run. Indented; all five workflows now parse. THE IMPORT'S APPROVAL CHECK COULD NOT FAIL. commit() built the plan and the approval packet from the same upload and then asked the writer whether they matched, so packet_matches_plan compared a hash against itself. The documented contract - "a human approves a specific, frozen plan, and the writer can prove nothing drifted" - did not exist in the web path: an admin could preview file A and commit file B, gated only by the needs-create group NAMES they ticked. The preview's planhash is now required at commit and checked against a freshly rebuilt plan. Their tests committed without previewing, which is what let this through; they go through the real flow now, and three new tests pin it - all confirmed to fail with the check stubbed out. endpoints.agentpackage QUIETLY GREW. It used to mean "wrap the staged exe in a ZIP"; with the upload routes it also means "choose the executable every future package installs and runs as SYSTEM". Before this, staging needed filesystem access to the server. The permission description still said only "generate and download a package", so an admin granting it could not see what they were granting. Reworded. NOTHING RECORDED WHAT WAS STAGED, OR BY WHOM. The manifest held version, size and timestamp; re-uploading a version replaces the bytes in place under the same label. A sha256 of the stored file is now recorded, and the upload is audit-logged with it - after an incident there was previously no answer to who put that binary on the fleet. Also documented the nine new routes in docs/api-inventory.json (that gate cannot run on the mirror, so it falls to us at promotion time again), regenerated the spec and the project map, and kept our own docs where they conflicted: docs/ is scrubbed from the mirror, so their DEV-BUILD-TEST.md still had the dev-be channel mapping we corrected, and their PLUGIN-HOOKS.md was a new 45-line file rather than our 737-line canonical one. Their journal section is appended to ours. Contract version comes across as 0.30.0 for a genuinely additive surface. Suite 2369, frontend 324, gate green. Scope: product
68 lines
3.0 KiB
Python
68 lines
3.0 KiB
Python
"""Alias and normalization tables for the WINC machine adoption dry-run.
|
|
|
|
This file is DATA, not logic. It is the single place a human edits when the
|
|
analyzer reports an unresolved value. Keep it boring: plain dicts, one entry per
|
|
line, lowercase keys. The analyzer lowercases and strips before it looks a value
|
|
up here, so keys here must be lowercase and already stripped.
|
|
|
|
Two independent problems get solved here:
|
|
|
|
1. eq1 -> business unit. The May export's eq1 column is a free-text value-stream
|
|
label (LG PARTS, SM SPOOLS, Large Spoo, HPTCR ...). It is dirty: truncated at
|
|
ten characters, inconsistently cased, and it does NOT match anything in the
|
|
live businessunits table (that table is a list of offices auto-created by an
|
|
earlier printer import). So every eq1 value must be mapped by hand to the
|
|
canonical business-unit name we want on the asset. A canonical name that does
|
|
not yet exist in the database is reported by the analyzer as "would need to
|
|
be created" - the analyzer never invents one and never writes one.
|
|
|
|
2. location code overrides. Most WM-<bay> codes resolve by simply dropping the
|
|
WM- prefix and matching a location by name (WM-J3 -> J3). A handful do not,
|
|
because the bay code carries a slash, a note in parentheses, or a room name
|
|
the location table spells differently. Those exceptions - and only those -
|
|
live here, mapping the RAW export location string to the exact locationname
|
|
already in the database.
|
|
"""
|
|
|
|
# eq1 (lowercased, stripped) -> canonical business unit name.
|
|
# The value on the right is what we intend to store; the analyzer checks whether
|
|
# it already exists in businessunits and flags the ones that do not.
|
|
EQ1_TO_BUSINESSUNIT = {
|
|
'lg parts': 'Large Parts',
|
|
'lg part': 'Large Parts',
|
|
'large part': 'Large Parts',
|
|
'sm spools': 'Small Spools',
|
|
'sm spool': 'Small Spools',
|
|
'large spoo': 'Large Spools',
|
|
'lg spools': 'Large Spools',
|
|
'lg spool': 'Large Spools',
|
|
'hptcr': 'HPT Rotor',
|
|
'bliskcr': 'Blisk Rotor',
|
|
'blisk': 'Blisk Rotor',
|
|
'leap x': 'LEAP-X',
|
|
}
|
|
|
|
# Raw export location string (lowercased, stripped) -> exact locationname in DB.
|
|
# Only for codes that do NOT resolve by dropping the WM- prefix. Leave a value
|
|
# as None to say "known to be unmappable, do not touch location for this row".
|
|
#
|
|
# The entries below the two None rows were promoted from the dry-run's
|
|
# high-confidence suggestions and verified to exist in the locations table. A
|
|
# slash-joined bay code (T6/U6) names two adjacent bays, but an asset carries a
|
|
# single locationid, so each maps to the FIRST (primary) bay - the deterministic
|
|
# choice a human confirmed. LD7W and LD6W are intentionally absent: they had no
|
|
# existing match and need a location created before they can be aliased.
|
|
LOCATION_OVERRIDES = {
|
|
'wm': None,
|
|
'wm-toolroom': None,
|
|
'wm-t6/u6': 'T6',
|
|
'wm-t9/10': 'T9',
|
|
'wm-u9/10': 'U9',
|
|
'wm-t4/u4': 'T4',
|
|
'wm-ld9w(ge90)': 'LD9W',
|
|
'wm-m6.3': 'M6',
|
|
'wm-l1-4': 'L1',
|
|
'wm-ld7w': None,
|
|
'wm-ld6w': None,
|
|
}
|