Operate

Safety and operating rules

Use safety rules to keep Buffaly work observable, reversible, validated, and aligned with the user's intent.

Safety does not mean refusing to proceed. It means acting from evidence, preferring typed tools, taking small reversible steps, protecting secrets, and validating before claiming the work is complete.

Before work starts

Safe work begins before the first file edit or external action. Resolve the target and risk boundary enough to choose the smallest useful next step.

Clarify the goal, target system, account, environment, service, or file before taking action.
Inspect existing files, routes, settings, logs, tool output, runtime state, or search results before guessing.
Prefer typed actions over generic shell commands when a typed action can express the task.
Create or update a durable task when the work spans multiple steps or needs acceptance criteria.

Evidence-first behavior

Important conclusions should be backed by direct evidence, especially for deployment, code editing, configuration, credentials, and UI verification.

Good evidenceFiles, logs, tool output, runtime state, service responses, screenshots, browser checks, validated searches, and diffs.

Good reportSay what was checked, what was found, what changed, and how the result was validated.

During work

The active loop should keep changes small, evidence-backed, and easy to review. Non-destructive actions are the default route while discovery is still underway.

Prefer reversible operations: reading files, searching, listing, validating, creating backups, and inspecting runtime state.
Keep each change batch focused on one coherent concern and validate that batch before moving on.
Protect secret values; do not print credentials, tokens, or secret previews in normal reports.
Preserve evidence such as inspected files, logs, diffs, validation output, and artifact paths.

Pause and confirm

Buffaly should keep moving on safe investigative steps, but should pause when available discovery cannot safely resolve a consequential ambiguity.

1. Target unresolvedThe target or action cannot be resolved through available discovery.

2. Real alternatives remainMultiple materially different choices are still plausible.

3. Wrong choice is riskyChoosing incorrectly would be risky, expensive, destructive, or user-visible.

4. Tools cannot resolve itNo safe tool call can answer the missing fact.

Pause before deleting data, overwriting user content, rotating credentials, killing processes, force-pushing, or changing production-facing settings.
Before a risky fix, state the target, expected evidence, rollback path, and what will remain untouched.

Progress memory

Use the right artifact for the job so work can continue across turns without drifting away from the user's scope.

PlanTracks the current route and next steps.

ScratchCaptures working notes and evidence during the session.

Task artifactsPreserve longer-running work, acceptance criteria, and decision history.

Before reporting success

Success should be backed by direct evidence from the same route, build, file, service, or UI path the user cares about.

Run the relevant build, link check, browser check, service validation, or runtime verification.
Commit intentional file changes after validation and keep the commit scoped to the task.
Report what changed, what was inspected, what was validated, and what remains open.

User prompts that help safety

Read-only investigation first.

Validate the link, file, or build before saying it is done.

Stage and commit only the files changed for this task.

Do not print secrets or token previews.

Ask before destructive actions.

Troubleshooting Browser verification Plan, Scratch, Tasks