Scheduled Documentation Maintenance

Use this prompt for a recurring, worktree-isolated audit of StratoFusion's canonical documentation. The scheduled run should prepare reviewable changes; it must not publish or deploy them automatically.

Recommended Task Configuration

• Run once each weekday after the normal merge window.
• Use an isolated Git worktree based on the latest origin/main.
• Start with workspace-write access and grant network access only for Git fetch and authenticated draft pull-request delivery.
• Review the first several runs and adjust the audit window or scope if the results are noisy.
• Keep human review and merge protection enabled.

Scheduled Task Prompt

You are working on StratoFusion. Audit the canonical documentation against the
latest implementation on origin/main and prepare documentation-only corrections
when evidence shows drift.

Before auditing, read AGENTS.md, README.md,
public/docs/developer/AI_OPERATING_PROTOCOL.md,
docs/ai-skills/15-ai-agent-prompts.md,
docs/ai-skills/13-code-review-checklist.md, and docs/ai-skills/08-testing.md.
Load the smallest additional domain skill set needed for the changed areas.

Use PowerShell and PNPM. Invoke Git Bash explicitly only for .sh scripts. Never
use or assume WSL.

Audit procedure:

1. Confirm that the checkout is an isolated worktree and that unrelated local
   changes are absent. If either condition is false, stop and report it without
   modifying files.
2. Fetch origin/main without rewriting local history. Inspect commits from the
   last three calendar days so weekend and delayed runs overlap safely. Repeated
   findings are acceptable; repeated edits are not.
3. Identify changes to user-visible behavior, API contracts, architecture,
   deployment or environment configuration, billing, providers, OAuth,
   AI Search, testing workflows, and rclone behavior.
4. Verify claims from implementation, tests, migrations, configuration, and
   existing interfaces. Do not rely only on commit messages, PR descriptions,
   generated files, or historical reports.
5. Compare verified behavior with the canonical documentation. Update only the
   smallest applicable files:
   - architecture: public/docs/ARCHITECTURE.md
   - API contracts: public/docs/API_REFERENCE.md
   - deployment and environment: public/docs/DEPLOYMENT.md
   - billing and trials: public/docs/SUBSCRIPTION_MANAGEMENT.md
   - rclone and the data plane: public/docs/RCLONE_SERVICE.md
   - testing workflows: public/docs/TESTING.md
   - user workflows: the applicable public/docs/user-guide file
   - top-level product status: README.md, only when the overview changed
   - repo AI guidance: the applicable docs/ai-skills file, only when agent
     operating guidance changed
6. Do not modify code, migrations, dependencies, generated output, dated
   reports, archives, consolidation-history, completed investigations, or
   historical runbooks. Do not create a new implementation report or bug-fix
   document for routine changes.
7. Do not invent behavior, commands, credentials, endpoints, limits, dates, or
   architecture. When evidence is incomplete or contradictory, leave files
   unchanged and report the ambiguity with file references.
8. Preserve provider-neutral terminology and the
   (provider, account, resource) boundary. For transfer-related documentation,
   distinguish source, destination, direction, operation type, destructive
   behavior, and relevant rclone flags.
9. Keep edits concise. Preserve existing structure and avoid restating the same
   change across several documents unless each document has a distinct audience.
10. Validate changed Markdown links and referenced paths, run git diff --check,
    and run the smallest applicable documentation or rendering tests. Do not run
    unrelated broad test suites solely because the task is scheduled.
11. Review the final diff for secrets, unsupported claims, accidental code
    changes, and historical-file edits.
12. If no correction is required, make no commit and return a short no-op report
    naming the commits and documentation areas reviewed.
13. If corrections are required and validation passes, commit only the approved
    documentation files on the isolated codex/ branch with a docs: commit
    message. If authenticated GitHub delivery is available, open or update one
    draft pull request targeting main. Never merge, deploy, force-push, or push
    directly to main.

Final report:

- Commits and changed areas reviewed.
- Documentation files changed, or an explicit no-op result.
- Evidence supporting each correction.
- Validation commands and results.
- Ambiguities, residual risks, and human decisions required.
- Commit and draft pull-request details when created.