Security and update workflow

This procedure serves pc-security-updates. It is reusable guidance, not a live inventory, advisory verdict or authorization. Use communication, sources, compatibility and the helper API for their detailed contracts.

Start and define the boundary

Use the current conversation engine interface and security_updates job. The engine owns the first menu and the commands PatchCairn: start, help, status, options, cost, settings, pause, resume, stop, and resolve; present their full names as PatchCairn: <command>, without replacing host slash commands. Natural language can select a known command; resolve ambiguous scope before acting. A bare Start opens only the menu, without session creation or host collection. An explicit assessment permits only its agreed read-only scope; session creation alone permits no collection.

Record the agreed computer/scope, exclusions, control style, timing and selectable checkpoints. Automatic control can continue only a concrete authorized scope with required gates; scheduling stores a proposal until separate authority creates a host schedule. Settings changes cannot broaden an earlier approval. Keep JSON and action bookkeeping with the assistant, not the owner.

Establish the real platform, architecture, supported backend/runtime and available research, shell/API, file, review and UI capabilities. Read the current engine documentation and helper API. A missing native adapter, immutable backend marker, supported runtime, independent review or OS permission is a capability hold. Do not imply a fixture or role name certifies host support. Begin each new PowerShell session with $env:TZ='UTC'; leave the OS time zone unchanged.

Create fresh appropriately scoped real records only for actual authorized work. Preserve backend/run/session identity; never promote fixtures or import another owner's inventory/approval. Register artifacts under owned work/ paths through the documented writer, with actual hash, observation UTC-Z, scope and limits. If a workflow session references an assessment ledger, bind the exact immutable run/backend and snapshot; reports are derived views, not another authority.

Build a usable installation map

For each selected component establish product/publisher, observed version/build, architecture, package identity, installation scope, actual owner/updater, channel/support branch and observation time. Separate machine, user, portable, project and application-bundled installations; record unresolved ownership rather than guessing from a name, PATH entry or catalogue match. Inventory adapters cover selected metadata, not every dependency. Do not use Win32_Product, execute unknown launchers, crawl private projects or dump environment/authentication files.

Map consumer requirements when relevant within approved scope. Preserve required Python/Node/Java/.NET/VC++ families, virtual environments, manager prefixes and side-by-side architectures. For an application bundle, propose its publisher's update; a global runtime update does not fix its private runtime. A project pin is a compatibility constraint, not permission to open private lockfiles or rewrite the project. Unknown consumers can justify a hold or separate scoped check; they do not justify deleting the older copy.

Research applicability and choose a target

Use current primary publisher release notes, lifecycle policy, security advisories and distribution notices. Check relevant vendor security news and official exploitation/incident alerts as well as advisory databases; third-party reporting is a discovery lead. Public queries contain public product/error identifiers, never raw logs, local paths, hostnames, account data or private package names.

For each advisory candidate record affected product/branch/range, fixed build or vendor backport, architecture/platform, required feature/exposure, support status, exploitation claim/source/date and the local facts that establish or prevent applicability. Use applicable, not applicable with reason, conditional/unknown, or not assessed. An old upstream version in a distro package may contain backported fixes; no update offer or published CVE does not prove safety. Keep availability, support, compatibility, applicability and actual remediation separate.

Record source ID, title, requested/final URL, publisher ownership, accessed UTC-Z, publication/revision date if available, claim supported and access limitation. News receipts distinguish publication date from event date. An inaccessible advisory leaves an explicit gap; a landing page is not its contents. Revalidate changing facts before action.

Choose a supported compatible stable/LTS target in the correct owner/channel/architecture, not the numerically newest release. Check OS requirements, dependencies, plug-ins, data/configuration migration, licensing/entitlement, known issues and restart needs. OS release transitions, firmware/BIOS, removal, new paid entitlement or channel migration require explicit scoped decisions.

Make changes concrete and reviewable

Create immutable plan bytes through the documented API. Every action needs:

Use official signed distribution where supplied. Windows verification distinguishes embedded/catalog signatures and the expected signer; other platforms follow the vendor's signed package/checksum/provenance procedure. A self-calculated hash identifies bytes, not authorship. HTTPS, a catalogue match, notarization or a valid unrelated signer is insufficient. Unavailable or failed required verification holds the action; never bypass it. Stage toolkit-requested downloads under work/; do not download/install tools merely to complete an assessment.

For integrated updates, use the current service's exact local-artifact catalogs when available: windows.msiexec.install consumes the reviewed owned .msi path, macos.installer.pkg the reviewed owned .pkg, and linux.dpkg.install_local the reviewed owned .deb. The service issues a handoff, not execution. Bind actual artifact native identity/SHA-256, publisher/signature, product/version, architecture/channel/source/scope and fixed argument grammar before the gate and recheck immediately before the coordinator's official call. Use pkgutil for PKG signer inspection; codesign of code is not PKG verification. Authenticate a DEB checksum through the official distribution's signed metadata chain. Require actual owner/OS consent; no extra properties, flags, force or substitute artifacts. See tool/source pairs and access limits.

Prechecking one file does not prove that a package-manager call later consumes it. Name/version/offer matching cannot substitute for exact consumption; the package-manager handoff stays held when that binding is unenforceable. Missing catalog/native capability or changed bytes/identity holds without a weaker executor. A local package's scripts, dependency/state effects and restart needs still need review and actual verification. OS/app repair handoffs currently remain held until supported typed recovery covers the exact component; ordinary-file ZIP recovery does not establish OS/package-state rollback.

The coordinator selects bounded work for these roles:

One coordinator owns mutations, UI and canonical writes. Specialists return uniquely identified bounded results; the coordinator records originals sequentially. For conversation sessions use the engine evidence-registration API with actual result bytes, scope and UTC observation, and the service/diagnostic methods for their separately bound records. Only matching assessment-record components use their owned artifact writer and evidence/agents/ layout. Do not insert unregistered files or mix these stores. Both adversarial reviewers independently inspect the same immutable plan/evidence before seeing each other's verdict. Missing review is a hold; two self-written perspectives are not independent. Resolve material blockers and retain dissent.

Explain the named plan or subset in chat: practical purpose, recommendation and alternatives, benefits, drawbacks, known/unknown money, download/storage needs and time/downtime, privacy/external effects, reversibility and unfinished risks. Use measured facts for estimates; say unknown when unavailable. Record the actual owner's instruction and message reference against exact action IDs and plan SHA-256 through the current engine approval interface. A review pass, approved=true, mode selection, schedule trigger or silence grants no authority. Preserve already-valid consent for unchanged routine actions.

Execute, pause and verify

Immediately before mutation, refresh material preconditions and the approved artifact/target. Obtain the engine's durable begin-operation receipt for that exact action/plan/evidence; only then coordinate the reviewed official CLI/API/package manager or supported UI. Engine/ledger data is not an arbitrary executor or OS sandbox. One active installer, servicing transaction or protected prompt at a time. Do not use blanket upgrade-all, pin/hash overrides, force, undocumented switches, manual bundle swaps or security-policy changes.

Explain normal authentication/UAC/Touch ID and let the owner complete it without collecting secrets. Give a concrete handoff if UI/elevation is unavailable. Stop on source drift, mismatch, refusal, lock, cleanup warning, unexpected restart/preservation behavior or partial/unknown result. Keep safe selected output, side effects and receipts. A consumed action is not retried automatically; a new supported recovery proposal needs reconciled evidence and its own appropriate review/consent.

PatchCairn: pause blocks new work immediately. Bring an active operation to its safe receipt/checkpoint without killing it. Before restart/process interruption record completed/consumed actions, active-operation identity, actual result, pending verification, required recovery and next owner step. Restarts and forced application closure are never inferred. On resume reconcile the same session against fresh installation/boot/receipt evidence; unknown outcomes remain held. resolve addresses a named pending item with evidence or a bounded decision, never asserts an unobserved fix. Stop preserves unresolved state and evidence.

For the fixed Windows MSI route, complete_external preserves actual code 3010 through installed_restart_pending, a fresh selected pre-restart boot observation, and the immutable original receipt. The same operation stays active; its action remains consumed. Use the engine's decide_restart for the actual owner's defer or exact owner-handled restart decision, respecting current scope and timing. After the owner-handled restart, complete_external_after_restart requires the original pending/decision bindings, actual boot transition, selected target and every original behavior observation. Final success requires the reviewed target and all checks to pass; failed/unknown behavior permits only a failed or partial result. An actual authorized boot retires the restart item, but failed/partial effects still need fresh effects/no-active-work/retained-recovery reconciliation and an actual owner decision before eligible replanning. Do not rerun the installer, translate its code to zero, schedule a restart or clear pause/stop. A stopped session may record a fresh actual owner defer/authorize decision solely for its retained exact unfinished MSI3010 effect; it stays stopped with no new job action, plan, checkpoint or ticket. An earlier valid decision can also support exact late outcome accounting. Code 1641 under /norestart is unexpected restart initiation and only an unknown outcome pending reconciliation. Follow the current service/engine contracts; missing decision or boot proof holds the same operation, and every final result retains code3010.

Finish operation records truthfully, then verify actual installation identity/version and active/loaded state, relevant behavior and the specific security criterion separately after required restarts. An installer exit, download, version string or empty update queue alone is insufficient. Report verified updates, already-current installations, pending activation/restart, failed/partial actions, vendor-managed dependencies, compatibility holds and unknown/unassessed scope. Close an assessment with holds honestly; do not mark deferred actions completed for cleanup. Offer only separate approved owned-artifact cleanup under recovery and cleanup.

For an eligible assessment-only conversation session, use the engine's complete_assessment contract after every agreed assessment stage and prior checkpoint has finished. It requires current scope authority, current schedule activation when applicable, no operation history/plan/approval/reviews/standing policy, an owned typed findings-and-limitations summary, separate fresh verification of its exact hash/evidence coverage, and the actual owner's closeout instruction. A selected finish checkpoint still waits for the owner's continue decision. This records no maintenance action in that session; it is not an all-secure or computer-unchanged finding. An ineligible or unfinished session can be stopped with findings preserved. Never manufacture a plan or action to obtain completed status.

Developed by Michael. Private session records belong locally under work/; this public guide contains no live computer records.