Jaipilot Maintainer Intent

Establish maintainer intent before changing code

Treat repository history as part of the task specification. A technically correct patch is not a useful contribution when it duplicates active work, conflicts with an explicit roadmap, targets the wrong branch, or ignores the repository's established solution shape.

This is a read-only preflight. It does not authorize a comment, issue, branch, commit, push, or pull request. Preserve the worktree and unrelated user work: never switch branches, reset, clean, stash, or overwrite files while researching.

Establish the exact source

1. Locate and read the complete repository guidance that applies before acting: CONTRIBUTING.md and linked contributor docs, applicable pull-request templates, repository instruction files, security, governance, developer, testing, and release guidance, and any AI-assisted contribution or disclosure policy. Check the root, .github/, docs/, and affected subtrees for scoped guidance; read the selected files completely. If a document is absent or inaccessible, report that fact instead of inventing a rule.
2. Record the repository, immutable revision, source issue or pull request, author, current state, target branch, head branch, and the user's intended delivery target. Distinguish a dependency bot branch from the default branch and from a human feature branch.
3. For a pull request, read the complete conversation: title, body, commits, force-pushes, issue comments, reviews, inline review comments, check failures, linked issues, and linked pull requests. Do not infer the current decision from the title or final diff alone.
4. Use only read access already available to the host. Do not expose credentials. Do not fetch or mutate refs merely to obtain history; ask before a read operation that would change local Git state. If relevant history is inaccessible, record that limitation and do not guess.

Use optional dependency-upgrade knowledge

If the user supplies or names CROSS_REPO_KNOWLEDGE.md, use it only for a dependency or version upgrade. For unrelated maintenance, report it as out of scope and ignore it. Do not discover or load the file unless the user explicitly names or supplies it. Match the exact coordinate, old and new versions, bot type and head, failure signature, build system, runtime floor, and contribution situation. Revalidate the source bot pull request, companion pull request, immutable revisions, maintainer feedback, and current outcome. Treat Accepted records as precedent, Maintainer-directed records as decision constraints, Candidate records only as diagnostic hypotheses, and Unadopted records as warnings rather than solutions. Only independently verified sources enter the evidence ranking below. Use matched records to choose the delivery channel and one final decision, and report their identifiers plus any rejected or superseded approach.

Search for the repository's answer

1. Search open and closed issues and pull requests in the same repository for the dependency coordinate, old and new versions, failing symbol or error, affected module, and proposed solution. Check for the user's own open work as well as other contributors' work.
2. Read the nearest accepted, rejected, reverted, and superseded examples. Prefer examples for the same dependency or subsystem; otherwise use the closest contribution type. Read their review discussion, not only the merged bytes.
3. Inspect local git log, git blame, and the introducing commit for the failing contract. Follow the producer of an invalid value before adding a caller workaround. Preserve the incumbent library or architecture unless repository evidence supports replacing it.
4. Identify contribution mechanics: direct default-branch pull request versus a patch onto an existing bot branch, required issue or Jira key, title format, generated files, sign-off, DCO, CLA, test and coverage expectations, and disclosure requirements. Never claim or accept a legal agreement for the user.
5. Detect branch churn. Repeated bot supersession or force-pushes lower the value of speculative work and require rechecking the exact head immediately before any authorized publication.

Separate evidence from inference

Rank evidence in this order:

1. explicit maintainer direction in the current source conversation;
2. an active or merged same-problem change and its review;
3. repeated accepted or rejected repository precedent;
4. contribution documentation and repository configuration;
5. code-history inference; and
6. general ecosystem convention.

Label inference as inference. Never convert silence, a stale bot pull request, or a passing build into a claim about maintainer preference.

Stop when decisive higher-ranked evidence determines a terminal decision. After an explicit current-thread maintainer direction, perform only the exact duplicate check and contribution-channel check needed to report the next action; do not enumerate unrelated repository history. When no such direction exists, inspect only the nearest relevant examples needed to establish a consistent pattern, and state residual uncertainty instead of continuing an open-ended search.

Choose exactly one decision

• PROCEED: repository evidence supports the change, no exact or near duplicate owns the outcome, no explicit wait or roadmap conflict exists, the delivery target is known, and required proof is feasible.
• JOIN_EXISTING: an active change already owns the same outcome. Contribute there only when the user authorizes that interaction; do not open a competing pull request.
• COMMENT: one maintainer decision is required before code would be useful. Draft the smallest precise question, but do not post it without user authorization.
• WAIT: a maintainer or source conversation explicitly depends on an upstream fix, coordinated release, branch movement, or other known event. State the event that would make the task ready.
• NO_ACTION: the work is obsolete, superseded, rejected by current policy, already solved, a duplicate, or not a real repository problem.

Any unresolved blocker prevents PROCEED. Do not write code first and use this decision afterward to justify it.

Hand off only a supported change

For PROCEED, name the repository-established delivery target before editing: the current change, an existing bot branch, or a direct pull request to the repository's normal base. Describe the smallest accepted solution shape, proof expected by prior reviews, and contribution mechanics. Then use the applicable JAIPilot implementation and review skills.

After PROCEED, use jaipilot-fast-execution when safe batching or bounded native parallelism can reduce wall time without changing the required proof. Default substantial Java commands to jaipilot-remote-java when the laptop has no concrete advantage; follow its upload consent boundary.

Report

Announce a completed decision only as **JAIPilot · Maintainer intent** — <decision>; <proof>. in progress or as the final outcome lead. Then render this exact flat section; do not nest bullets: JAIPilot impact

• Maintainer intent:
• Evidence: Apply impact-reporting.md, then report evidence, conflicts, rules, decision confidence/target/action, limitations, and any publication.