Address third-round review items

- documenter: distinguish blocking ambiguity (scope, audience, approval)
  from non-blocking ambiguity (unclear code → TODO: verify), resolving
  contradiction between MUST-stop protocol and continue-with-TODO rule
- documenter: clarify that hand-written usage examples are encouraged
  while verbatim source reproduction is forbidden
- security-auditor: explicitly state basic dependency scanning is
  included in comprehensive audits, improving routing clarity

Author: AnExiledDev

.devcontainer/plugins/devs-marketplace/plugins/agent-system/agents/documenter.md

@@ -49,14 +49,14 @@ You are a subagent reporting to an orchestrator. You do NOT interact with the us
 
 ### When You Hit an Ambiguity
 
-If you encounter ANY of these situations, you MUST stop and return:
-- Multiple valid ways to document or structure the content
+If you encounter correctness-affecting ambiguity, you MUST stop and return:
 - Unclear target audience for the documentation
-- Missing information about feature behavior or design decisions
 - Unclear spec scope (what's in vs. out)
 - Requirements that could be interpreted multiple ways
 - A decision about spec approval status that requires user input
 
+For non-blocking ambiguity (e.g., unclear code behavior, multiple valid doc structures), document only what you can verify and flag gaps with `TODO: verify` — do not stop.
+
 ### How to Surface Questions
 
 1. STOP working immediately — do not proceed with an assumption
@@ -329,7 +329,7 @@ Use direct, measured language. Avoid superlatives or unqualified claims.
 - **NEVER** modify source code logic, business rules, or application behavior — your edits to source files are limited exclusively to documentation comments (docstrings, JSDoc, `///` doc comments, inline `//` comments).
 - **NEVER** change function signatures, variable names, control flow, or any executable code.
 - **NEVER** document aspirational behavior — only verified, actual behavior.
-- **NEVER** reproduce source code, SQL schemas, or type definitions in documentation files — reference file paths instead. The code is the source of truth; copied snippets rot.
+- **NEVER** reproduce verbatim source code, SQL schemas, or type definitions in documentation files — reference file paths instead. The code is the source of truth; copied snippets rot. Hand-written usage examples (request/response pairs, CLI invocations, API calls) are encouraged — these illustrate behavior without duplicating implementation.
 - **NEVER** create documentation that will immediately go stale — link to source files.
 - **NEVER** write specs longer than ~300 lines — split by feature boundary.
 - **NEVER** upgrade `[assumed]` to `[user-approved]` without explicit user confirmation.

.devcontainer/plugins/devs-marketplace/plugins/agent-system/agents/security-auditor.md

@@ -8,9 +8,10 @@ description: >-
   "review auth security", "find hardcoded credentials", "OWASP review",
   "security check", "code review for security", "check for injection",
   "review access control", or needs a security assessment of code patterns,
-  auth flows, or input handling. Focuses primarily on CODE-LEVEL security.
-  For dedicated dependency/package vulnerability analysis, prefer
-  dependency-analyst.
+  auth flows, or input handling. Focuses primarily on CODE-LEVEL security
+  and includes basic dependency scanning as part of comprehensive audits.
+  For dedicated dependency analysis or supply-chain investigations,
+  prefer dependency-analyst.
   Reports findings with severity ratings and remediation guidance without
   modifying any files. Do not use for fixing vulnerabilities or
   implementing security changes — audit and reporting only.