Update stakeholder-review tool prohibition and java language guidance

Author: cowwoc

client/plugin/lang/java.md

@@ -58,3 +58,25 @@ See LICENSE.md in the project root for license terms.
 | `i += 1` | Hides intent for simple increment/decrement | `++i` (or `i++` when expression semantics require postfix) |
 | `i -= 1` | Hides intent for simple increment/decrement | `--i` (or `i--` when expression semantics require postfix) |
 | Test package names with internal `.test.` component (for example `a.b.test.c`) | Inconsistent package topology | End test package names with `.test` (for example `a.b.c.test`) |
+
+## Javadoc Terminology
+Project rule (required): Javadoc must be understandable to a reader who is new to this codebase. Never assume familiarity with internal/project-specific terms.
+Assume users/readers are unfamiliar with project jargon unless that term is defined in the same Javadoc block or linked to its canonical definition.
+
+Terminology clarity requirement: for every project-specific term, Javadoc must either define it in place or link to the canonical definition section in another file. Do not leave jargon unexplained.
+This explicitly includes terms like `setup-input`, `topic`, `topic files`, `carry-forward`, and other workflow-specific labels.
+
+Required behavior: every project-specific term in Javadoc (for example workflow labels, abbreviations, and acronyms such as `setup-input`, `SPRT`, `topic files`, `carry-forward`) must do one of the following at first use in that Javadoc block:
+1. Define the term inline in that Javadoc block.
+2. Link to the exact canonical file/section that defines the term.
+
+If no canonical definition exists yet, create one in project docs first, then link to that new canonical section.
+This applies to class docs, method docs, field docs, and all tags (`@param`, `@return`, `@throws`, `@see`, etc.).
+This is mandatory for all project-specific terminology.
+Review enforcement: any Javadoc that uses project-specific terminology without an inline definition or canonical link is non-compliant and must be fixed before merge.
+
+| Pattern | Issue | Fix |
+|---------|-------|-----|
+| Javadoc uses any project-specific term (for example `setup-input`, `topic files`, `carry-forward`) without definition | Readers cannot infer exact meaning, causing misuse and brittle maintenance | Javadoc **must** define every project-specific term at first use, or link to the canonical file/section that defines it |
+| Javadoc assumes reader familiarity with internal workflow jargon | New contributors and external reviewers misinterpret behavior and constraints | Do **not** assume familiarity: include a short in-place definition or a direct link to the canonical terminology file/section |
+| Javadoc links to a vague location (for example just a directory or repo root) instead of a canonical definition | Readers still cannot resolve terminology precisely | Link to the exact defining document/section (for example a specific skill/rule section or glossary heading), not a broad parent location |

client/plugin/skills/include/stakeholder-review.md

@@ -522,8 +522,9 @@ You are the {stakeholder} stakeholder reviewing an implementation.
 This is the review task. Do not acknowledge workspace, project, AGENTS.md, or setup instructions. Do not summarize
 what rules you will follow. Start the review immediately and return only the JSON review object requested below.
 
-Reviewer agents are leaf reviewers. Do NOT call `spawn_agent`, `wait_agent`, `list_agents`, `followup_task`, the
-Task tool, or any other agent-management tool. Do NOT wait for, poll, inspect, or coordinate with other stakeholders.
+Reviewer agents are leaf reviewers. Do NOT call `spawn_agent`, `wait_agent`, `list_agents`, `followup_task`,
+`assign_task`, the Task tool, or any other agent-management tool. Do NOT wait for, poll, inspect, or coordinate with
+other stakeholders.
 Perform only your own review and return exactly one JSON review object directly to the parent.
 
 ## Review Context