Issue Campaign

Issue Campaign

An issue campaign is a repeatable solo sequence of exhaustive discovery, issue publication, one unified implementation pull request, and renewed discovery. The main agent owns every phase and spawns no subagent other than the read-only commit early-warning pass that development.md defines.

Use the multi-agent skill and its issue-campaign procedure instead only when the user explicitly asks for a parallel or multi-agent issue campaign.

For the explicit continuation under issue #1775, read its campaign procedure. It keeps the existing shared checkout and pull request with ordinary CI, instead of the generic parallel worktree and cancellation flow.

The user's requested phase boundary controls how far to proceed. Do not infer permission to publish issues, push branches, open pull requests, or merge from an audit-only request.

Apply AGENTS.md's Choose the principled course rule to every admission, disposition, implementation, and review decision.

Read the project, development, and review skills before starting. Use the review skill's Solo Issue Discovery Rounds. Read development.md in full only when implementation is authorized.

Campaign Knowledge Base

Create .wiki/<campaign>/ with a short filesystem-safe campaign name. Preserve and reconcile an existing campaign directory.

Keep concise, current Markdown documents for:

• repository provenance, architecture, validation ownership, and product boundaries;
• experiments, reproductions, dogfooding, and related issue or pull-request history;
• every raw candidate, its evidence, dependencies, and final disposition;
• candidate combinations, splits, rejections, deferrals, and the evidence supporting each decision;
• each round's frozen commit, dependency lock, provisioning command, supported environment contract, and audited-surface and matrix results; and
• the published-issue DAG, internal implementation order, the unified cycle pull request, CI and Self-Review iterations, external blockers, official GitHub createdAt-to-mergedAt cycle timing, and cleanup state.

Record raw candidates before fact-checking. The knowledge base is the durable place to collect overlapping observations, then combine, split, rewrite, reject, or defer them without losing why.

Record every audited path and executed cell against its evidence, and record an absent check as absent rather than omitting it. A round whose notes cannot distinguish an executed check from an unrun one cannot support Discovery Ends Only On An Empty Round.

The knowledge base supports the campaign but is not the final issue body. A published issue must stand alone without access to .wiki.

Discover Issues

Freeze one exact commit before every round and work from it with a recorded dependency lock and provisioning command. Derive the supported environment contract from package engines, public documentation, repository CI, peer requirements, and published package behavior rather than narrowing it ad hoc. Never combine results from different commits, and never accept a stale, unprovisioned, skipped, or sampled harness as full-round evidence.

Perform complete Solo Issue Discovery Rounds over every tracked repository surface, repeating them until one comes up empty. Source is only one evidence layer. Exercise real workflows and inspect relevant upstream behavior, history, generated artifacts, consumers, fixtures, public documentation, and closed decisions. For nestia that means running the generators and reading what they emit: Swagger documents, SDK libraries, mockup simulators, and generated e2e suites are product output, and a defect visible only in emitted code is still a defect.

Cover this matrix as a floor, and add the dimensions source and history reveal:

• every decorator and its option set;
• Express and Fastify for every request and response path;
• the Swagger document, SDK library, mockup simulator, and generated e2e suite one controller produces;
• INestiaConfig options and CLI flags, including the --project and --config paths;
• equivalent aliases, interfaces, classes, intersections, unions, generics, and re-exported or ambient declarations;
• user-global, default-library, module, package, and runtime-native provenance;
• transform-option interactions;
• valid, invalid, malformed, maximum-width, and one-past-boundary inputs;
• repeated generated-byte identity and clean tarball consumers; and
• supported Node, module-resolution, operating-system, and CLI paths.

Every interaction that reaches shared control flow is a separate cell, and every positive cell has a one-axis negative twin. Record negative results and killed hypotheses so a later round knows which exact experiment already ran.

Treat the development skill's Forbidden section as a retrospective audit contract, not only a rule for future changes. In every complete round, inspect the implementation and history for a verified violation, even when existing tests pass. Prove the classification from purpose, control flow, consequence, and history. Resemblance or stylistic preference is not evidence.

Do not stop after finding enough work for a pull request. Complete the entire scope, adjudicate the full candidate pool, and publish only the surviving issues when authorized.

A verified in-repository correctness, contract, data-integrity, build, test-oracle, documentation, packaging, workflow, or Forbidden violation is meaningful regardless of severity, rarity, legacy status, or malformed-input trigger. Do not downgrade a proved defect to an observation to satisfy the stop rule, and do not let a deferral hide it: an unresolved verified defect blocks campaign completion.

Every Round Is Full-Scope

Every round re-audits the entire declared scope against the current integrated state. A round is never partitioned: not by package, file, concern, platform, or validation lane, not by the areas the last cycle happened to touch, and not by splitting the scope across rounds so that each one covers a slice. A merged cycle changes the state every earlier conclusion rested on, so what an earlier round read is not coverage for this one. The review skill's Non-Negotiable Review Law states the same rule for every round and review the campaign runs.

Only an explicit user instruction or an existing public product contract can exclude a surface or environment from the scope. The campaign cannot narrow itself, and an unresolved support-policy question leaves the round incomplete.