project-management

Project Instructions

Problems with a kendex-owned skill go through kendex report; check ownership in the file first.

Project Management

Wrappers run in the primary session: they own the user dialog and every tracker mutation. TPM workflows analyze and return JSON inline; they never mutate the tracker and never write the artifact.

Disposition

• Creation bar. File an issue only when all three hold:

  • it changes what a user or operator experiences, or blocks work that does;
  • no open issue, active branch, or one-line fix already covers it;
  • someone could pick it up and finish it without a new investigation.

  A reproducible anomaly with evidence in hand passes all three as an investigation issue. Everything else is declined with one line in the report: no issue, no placeholder, no tracking artifact. Failing the bar: a severe-sounding edge case no real input reaches, a hypothetical of low severity, a coverage ask for a path that has not regressed, a refactor that neither changes behavior nor unblocks user-visible work, and the classes in ../orch/references/finding-disposition.md § Decision flow Step 0, whatever source the candidate arrived from. Two exceptions file at any likelihood: a security or data-loss defect a shipped path reaches, and an edge case whose failure is critical harm or financial loss.

• Name what reaches it. Every issue carries a Reached by: line giving the user action, run, check, or shipped producer that arrives at the defect; an owner-directed item names the ask.

  • The thread a finding came from, a shape ("a name containing a quote"), or something true in theory is not a reach, and an item with nothing to name is a decline, not an issue. The judgement is the author's: issues create under LINEAR_REQUIRE_REACH refuses only a body with no Reached by: line, an unsubstituted placeholder and a null token (TBD, n/a, none, -) counting as absent.
  • A filing whose source is a review round carries, at priority 2, a Symptom: line naming the run, the user, or the red check that already showed the defect (--review-born). Priority 2 from any other source is structural, reports no symptom, and is not checked for one. Where a review-born finding files at all is ../orch/references/finding-disposition.md § Filing bar.

• Burn down more than you create. Every audit that reads an issue backlog sweeps its comparison set for issues the codebase has already satisfied, duplicated, or superseded, and proposes those for cancellation in the same pass, along with every active issue that fails the creation bar as it stands today. Report created N / closed M. project-order reorders projects, reads no backlog, and does not sweep.

• Ask about work, never about mechanics. The user decides what gets created, cancelled, and activated. Labels, priorities, relations, hierarchy, sort order, and project moves are corrections the workflow applies on its own authority.

• Research is part of planning, not a work item. Gather prior art, vendor docs, and approach comparisons inline during planning as an artifact on disk that issues cite. A tracker research issue exists only when the research is delegated as standalone work: run by the researcher agent, or prepared for later pickup (research-spike).

• One approval per decision. Ask the user to approve a body of work once, at the roadmap plan gate. Creation re-asks only what changed after that answer.