Organize actionable issue queues, dependencies, and agent work claims #1895

Goal

Make the next actionable PerlOnJava work visible, distinguish organizational work from project bugs/features, and let agents claim work without implying permanent ownership.

This replaces #1593 with a smaller scope. The earlier audit and reporting guidance already exist in dev/design/issue-organization.md and docs/guides/issue-triage.md; their remaining planning conventions need to reflect agent execution. At the 2026-10-27 audit there were 68 open issues, with only one lacking labels and an area, so broad label normalization is no longer the main problem.

Work to deliver

1. Distinguish organizational and project work

• Organizational issues change how work is selected, coordinated, reported, or released; this issue is an example.
• Project issues deliver runtime/compiler behavior, compatibility, performance, ports, or product features. An issue about fixing release tooling may itself be a project deliverable; classify by the requested outcome rather than its existing area label alone.
• Keep these as separate planning views/queues. Retain technical area labels as a separate dimension; area:release alone is not the organizational/project distinction.
• Choose a small, explicit convention for recording the distinction using issue metadata or the planning index. Avoid requiring a large new label taxonomy.

2. Publish a reviewed next-work shortlist and dependencies

• Refresh candidate issues against current issue/PR state. Distinguish work needing investigation, ready implementation, active work, blocked work, and work awaiting verification.
• Record priority rationale, next action, acceptance evidence or missing information, and actual blockers for the shortlist. Priority and readiness are separate decisions.
• Rewrite reference counting with complete Perl-compatible ownership semantics #1649 is already being worked on. Identify which candidate issues actually depend on its delivered ownership paths, record the specific unblock condition, and keep those out of the ready implementation queue. Related symptoms or shared areas alone do not establish a dependency.
• Group project work when it shares implementation code, test infrastructure, or a concrete dependency. Use cross-links for loose relationships and finite parent issues only for a shared deliverable with completion criteria.
• Do not force equal-sized groups or turn every planning group into a new parent issue. Groups support agent task selection; they are not an additional priority scale.

3. Record temporary agent work claims

• The project has no stable subsystem ownership model: implementation is executed by agents. GitHub assignees are optional and must not be required as a proxy for an agent.
• Use a lightweight shared claim record identifying the issue/scope, agent or session identifier, current branch/PR or durable investigation note, next action, and last checkpoint.
• Specify how agents check for an existing claim, publish a claim before implementation, and release or hand off work. Handle overlapping changes explicitly.
• Treat an old checkpoint as a reason to reconcile the claim, not permission to overwrite work or silently assume it is abandoned. Any claim mechanism must state its concurrency limits; comments alone cannot guarantee exclusive assignment.
• Reuse existing coordination mechanisms where applicable. This issue does not require building a scheduler or distributed locking system.

4. Keep agent history and handoffs concise

Long-running agent work must remain resumable without reading an ever-growing chronology. Add explicit instructions in AGENTS.md and the relevant coordination/triage guidance:

• Keep a short, authoritative current-state checkpoint, normally about 200-400 words, containing the issue and source commit/branch/PR, completed result, decisive evidence, unresolved question/blocker, and immediate next action. Use links or artifact references for detailed evidence.
• Refresh or replace the designated current-state summary as work progresses. Record material decisions and phase completions; avoid appending a command-by-command narrative, repeated plans, or repeated status.
• Keep conversation updates and issue comments brief and focused on meaningful changes. At session handoff or context compaction, produce a self-contained checkpoint and resume from it rather than reconstructing the full chronological history.
• Capture complete build/test output in separate logs or durable artifacts as required by the existing validation rules. Put commands, source identity, result counts, and evidence links in the summary instead of pasting raw output. Do not discard required failure evidence, unresolved findings, or decisions to meet the word guideline.
• Preserve immutable history and append-only coordination protocols. Maintain or reference a separate current-state summary rather than truncating a mailbox, deleting evidence, or rewriting another agent's messages.

The word range is a default for the active checkpoint, not a limit on necessary design documentation or full test evidence. The goal is bounded working context and usable handoffs.

5. Align the existing guidance

Update AGENTS.md, the triage guide, and the design document to describe the adopted minimal workflow, including organizational/project views, dependency handling, agent claims, concise checkpoints, and the next-work shortlist. Replace the mandatory human-owner/two-issues-per-owner assumptions and mark superseded rollout steps clearly.

Acceptance criteria

• Organizational and project work can be viewed separately through a documented, consistently applied convention.
• A bounded shortlist of current project work records rationale, next action, readiness, and blockers; its size follows the available actionable work.
• Candidates dependent on Rewrite reference counting with complete Perl-compatible ownership semantics #1649 identify the required delivered path or milestone and do not appear ready while that dependency is unresolved.
• Groupings have an explicit technical or delivery rationale; loose thematic similarity is not recorded as a blocking dependency.
• Agent claims, checkpoints, handoff/release, and stale-claim reconciliation have a documented shared location and concurrency limitations, without requiring permanent owners or GitHub assignees.
• Agent instructions require concise current-state checkpoints and linked full logs; long-running work can be resumed from the latest checkpoint without reading the full chronology.
• AGENTS.md, docs/guides/issue-triage.md, and dev/design/issue-organization.md agree with the implemented workflow; the planning documents link this replacement.

Implementation

Implemented in PR #1896, source 7635064a7bf7b753db170acbfd99aae6efa1ec3c; awaiting review and merge. The skill entry points are shorter, with problem-solving tips retained in linked references. Repository and skill offline links pass, and all 15 skills validate.

Scope boundary

A GitHub Project, additional issue forms, intake automation, scheduled triage, comprehensive relabeling, and release milestones are optional later proposals. None is required to finish this issue. Existing reporting and regression-validation requirements remain applicable.