Reconcile infrastructure documentation with live deployed state

Why use this

1. Infrastructure notes can describe yesterday’s deployment while operators rely on them during an incident. A host may be reachable yet run different containers, disabled services or renamed units that no longer match the documented inventory.

2. This job could build a dated comparison between recorded intent and observed state. Keeping discrepancies separate from proposed fixes would help maintainers update knowledge without turning a documentation task into an unreviewed production change.

Why an agent / simpler alternative

Useful judgment

Interpret service and host output and reconcile it with inconsistent operational notes.

Simpler alternative

Use configuration-management inventory when it already captures the required deployed state.

Unsuitable when

The environment cannot provide read-only inspection or contains secrets that cannot be safely excluded.

Proposed inputs

1. Name

   Infrastructure notes

   Owner

   System owner

   Minimum scope

   Scoped host list, expected services and documentation conventions

   Quality check

   Identify the authoritative environment and stale aliases.

2. Name

   Approved observation scope

   Owner

   System owner

   Minimum scope

   Permitted hosts and read-only service/container queries

   Quality check

   Exclude secret values, customer data and mutation commands.

Access and setup — proposed or unknown

Proposed minimum

1. Use explicitly authorized read-only inspection and a documentation branch or copy; record capture timestamps.

Compatibility unknowns

1. Unknown: SSH permissions, host reachability, service naming and runtime access.

External actions requiring approval

1. Changing services, deploying fixes, expanding credentials or publishing sensitive infrastructure details.

Expected deliverable and review checks

Proposed artifact

Inventory update proposal with observed state, observation time, evidence pointer and discrepancy classification.

Critical checks

1. Failed access is marked unknown rather than interpreted as a stopped service.

2. Production, staging and retired hosts remain clearly distinguished.

Missing output evidence

No new workflow run or output inspection is performed for this editorial layer. The linked implementation evidence retains the original source-specific outcome and artifact limits.

Failure signals and proposed responses

1. Signal

   A host cannot be reached during the observation window.

   Why it matters

   The inventory could incorrectly mark its services removed.

   Proposed response

   Keep prior knowledge with a stale/unknown label and request a later authorized check.

2. Signal

   A container name changes while the underlying service remains the same.

   Why it matters

   The inventory may duplicate or lose a service relationship.

   Proposed response

   Compare stable configuration identifiers and ask the owner to confirm the mapping.

Effort and cost — unknown

Setup work

1. Define safe observation commands and inventory identifiers.

Ongoing review

1. Review discrepancies and refresh timestamped observations after deployments.

Unknowns

1. Unknown: access setup effort, network availability and documentation-maintenance cost.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

A synthetic inventory lists a renamed container, an unreachable host and an unexpected active service.

Acceptance checks

1. The unreachable host remains unknown.

2. The other discrepancies become review items without proposed automatic remediation.

Stop conditions

1. A mutation command, secret disclosure or additional persistent access is required.

Limits

1. The initial proposed task is observation and documentation; identifying drift does not authorize changing infrastructure.