Ln 61 Repository Publisher

Repository Publisher

Goal: Publish only changes the user has authorized, then verify the result from the remote source.

Execution contract: The checklist defines completion. Track each item internally as PENDING, PROVEN with evidence, CLEARED with evidence its condition is absent, or UNPROVEN with a gap; reading, delegation, tool failure, a zero exit status, or a self-reported success is not proof; only the observed outcome is. Reconcile after each section. Before returning, resolve all PENDING, count only PROVEN and CLEARED, and apply verdict and approval rules to every gap. Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. When no one can answer during the run, state the exact question and apply the skill's verdict for the remaining gap instead of waiting or guessing. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method. Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims. On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.

Tool Routing

Prefer compact Git output first, then open the full diff for files that will be staged. Never pipe commands in a way that hides the failing exit code.

Use hosting APIs for remote facts and Git for repository facts. Local distribution or deployment state cannot prove that a remote consumer update works.

Checklist

Establish scope and evidence

• Confirm the user explicitly requested a commit and push and identify the intended branch.
• Read repository instructions, release rules, and the current branch policy before mutation.
• Check git status -sb, staged and unstaged diffs, untracked files, remotes, and recent commit style.
• Identify unrelated user changes; do not stage them without explicit whole-worktree authorization.
• Inspect deletions and generated files as carefully as edited text.
• Check whether behavior, installation commands, catalogs, layout, or the public site require matching documentation updates.
• Do not change versions, tags, or release metadata during an ordinary publication unless the request or repository policy explicitly includes them.
• For marketplace edits, confirm every stable identifier is unchanged unless an intentional migration was approved.
• When multiple host catalogs exist and repository policy requires parity, confirm they contain the same distribution units in the required order.
• When metadata is duplicated across manifests or catalogs, confirm descriptions and source paths agree with the canonical source.

Validation Routing

• Discover and run repository-native validation commands before generic checks.
• For changed skills, run repository-required or host-native skill validators, or perform their documented manual fallback.
• For changed plugins or packages, run repository-required validators, or perform their documented manual fallback.
• Run every host-native strict validator whose distribution surface exists and changed or is required by repository policy.
• Run only the catalog parity, manifest parsing, stale-reference, local-link, and whitespace checks required by the repository and affected surfaces.
• Run only relevant product tests; do not invent a heavyweight release gate absent from repository policy.
• Stop before commit on a confirmed failing required check unless the user explicitly accepts the failure.
• Record skipped checks with the exact missing dependency or environment.

Synchronization and Commit

• Fetch the target remote and compare local HEAD with the remote branch before committing.
• If behind or diverged, inspect both sides and reconcile within the authorized branch workflow while preserving user changes; stop for unresolved semantic conflicts or a required history rewrite. Never force-push implicitly.
• Stage explicit paths when the worktree is mixed; use whole-worktree staging only when the user approved all changes.
• Review the cached diff and diffstat after staging; ensure required checks cover this exact tree, rerunning only checks invalidated by synchronization or subsequent edits.
• Exclude secrets, local caches, temporary artifacts, and unintended credentials from the staged set without deleting user-owned files; if an intended change contains a secret, block that publication and report redacted evidence.
• Match the repository's commit-message convention and summarize the entire staged change.
• Preserve configured commit signing and attribution policy; do not invent contributor identities or disable required signing.
• Create the commit and capture its full SHA.
• Push to the authorized branch without changing branch protections or using force.