Turn approved infrastructure context into a runbook

Why use this

1. An operator inheriting infrastructure may find useful commands scattered across configuration and informal notes. A command that worked once can depend on an undocumented host, version or privilege level that makes it unsafe to reuse blindly.

2. A source-linked runbook draft could expose prerequisites, expected observations and failure boundaries before anyone follows it. It would preserve untested commands as proposals and keep secrets or environment-specific values out of reusable documentation.

Why an agent / simpler alternative

Useful judgment

Connect configuration details to operating steps and identify missing prerequisites or ambiguous commands.

Simpler alternative

Edit an existing maintained runbook when only a small known procedure changed.

Unsuitable when

The task requires executing commands to infer behavior without explicit operational authority.

Proposed inputs

1. Name

   Approved configuration excerpts

   Owner

   System owner

   Minimum scope

   Relevant files with secrets and unrelated services removed

   Quality check

   Record environment and version context.

2. Name

   Operational purpose and boundaries

   Owner

   Operator

   Minimum scope

   Intended procedure, permitted audience and known recovery expectations

   Quality check

   Identify actions that require separate approval or expert judgment.

Access and setup — proposed or unknown

Proposed minimum

1. Read-only sanitized files and a private documentation draft.

Compatibility unknowns

1. Unknown: exact runtime, system versions, command availability and environment parity.

External actions requiring approval

1. Executing commands, changing infrastructure or publishing sensitive operational details.

Expected deliverable and review checks

Proposed artifact

Runbook draft with prerequisites, command placeholders, observable checks and unresolved recovery questions.

Critical checks

1. Each procedure identifies its environment and evidence basis.

2. Untested commands are not labelled verified; secret values are absent.

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 command assumes a different service version.

   Why it matters

   Following the runbook could fail or affect the wrong configuration.

   Proposed response

   Label the version dependency and request operator verification.

2. Signal

   A copied configuration contains a credential.

   Why it matters

   Publishing the guide could expose persistent access.

   Proposed response

   Remove the secret and use a nonsecret placeholder with approved retrieval instructions.

Effort and cost — unknown

Setup work

1. Define the procedure scope and sanitize source material.

Ongoing review

1. Have operators validate commands and maintain version notes.

Unknowns

1. Unknown: documentation gaps, safe-test availability and maintenance effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invented notes contain a version-specific restart command and a credential-shaped placeholder marked secret.

Acceptance checks

1. The version assumption remains explicit.

2. No secret value is carried into the reusable draft.

Stop conditions

1. A live command or security-sensitive change is needed.

Limits

1. Editorial operating-document aid; a written runbook is not evidence of safe execution.