AGENTS

MoFaCTS Wiki Agent Guide

Last Updated: 2026-10-09

Purpose

• Repository: C:\dev\MoFaCTS.wiki
• Canonical user and developer documentation for MoFaCTS behavior, workflows, setup, and operational guidance.

Sibling Repositories In This Workspace

• C:\dev\MoFaCTS (main codebase; application source lives under mofacts/)
• C:\dev\mofacts_config (config and content definitions)

The configuration repository is passive storage. MoFaCTS owns upload-time validation. Do not require manifests or run content audits there for storage, conversion, commits or pushes unless explicitly requested.

When To Inspect Siblings

• If user-facing behavior or workflows change in code, inspect C:\dev\MoFaCTS\mofacts and update wiki pages accordingly.
• If configuration requirements, field names, schemas, or setup steps change, inspect mofacts_config and keep docs aligned.

Cross-Repo Coordination Is Expected

• Do not assume this wiki is self-contained.
• Update docs to match current behavior and current config expectations.
• Remove obsolete or contradictory guidance rather than preserving parallel old and new narratives.
• MOFACTS_CONFIG_REPO and MOFACTS_WIKI_REPO, when set, must resolve to the canonical sibling paths above. Stop on a mismatch. If absent, verify and use those existing directories; absence alone is not a problem. Do not create substitute repositories.
• Consult the main repository's maintained CHATGPT_CONTEXT.md for background and historical decisions, then verify implementation claims against current source.

Wiki Audits

• Review application commits in chronological order from the recorded baseline. For each commit, inspect wiki relevance, check or update the affected documentation against current source, then mark it done in Wiki-Documentation-Audit.md with the action or a no-change reason.
• Keep draft, source-verified, rendered, and published status distinct. A later commit can supersede an earlier contract; document the current behavior and record that relationship.
• After commit reconciliation, check every page for audience fit, redundant reading paths, internal links, examples, and navigation. Prefer one comprehensive page with an internal index over splitting a topic into many small pages.
• Preserve useful authoring detail. Keep implementation ownership and operational commands in clearly identified technical sections and role-appropriate pages.
• Stay on the current branch, preserve unrelated edits, and do not commit or push without explicit user instructions.

Editing Rules

• Keep filenames and titles in existing wiki style.
• Prefer targeted edits over broad rewrites when possible.
• Preserve internal links, image paths, and _Sidebar.md consistency.
• Include exact field names and concrete steps for operationally important behavior.
• If a file is necessary to complete the task correctly, work in it even if it was not part of the initially expected file set.
• Do not comment on unrelated local diffs, pre-existing modified files, or surprising worktree state unless they materially conflict with the task or create real risk.