Operator Logs: What to Record After Each Run

Operator logs make Rocky work reviewable. They do not need to be heavy, but they should capture enough context for a human to understand what happened later.

Minimum log fields

For important workflows, record:

• Request: what the user or event asked for
• Scope: what Rocky was allowed to do
• Sources inspected: files, URLs, dashboards, APIs, messages, or docs
• Actions taken: edits, commands, posts, drafts, generated files
• Approvals: what was approved, denied, or left pending
• Verification: test output, screenshot path, response code, live URL, or rendered artifact
• Blockers: missing credentials, unavailable source, failed tool, unclear permission

Example

Run: weekly-site-check
Sources: public homepage, /wiki, server logs
Actions: no changes; identified one stale link
Verification: curl returned 200 for core pages
Approval: owner needed before editing footer link

Where logs should live

Use the simplest durable location that fits the workflow: a JSON state file, markdown run log, ticket comment, private dashboard entry, or gateway message history.

Privacy warning

Do not store secrets, tokens, cookies, full customer records, or unnecessary personal data in logs. Keep evidence useful but sanitized.