nexarch 0.12.34 → 0.12.35

package/dist/lib/skills.js

@@ -104,18 +104,28 @@ skill is the check-in → claim → complete loop for working that queue.
 - \`nexarch_check_in\` previews pending commands and draft/proposed
   applications for this agent. It does **not** claim or change anything —
   safe to call any time, including proactively at the start of a session.
-- If you already know which application you're operating in — you're
-  working inside its repo, or it was named earlier in this conversation —
-  pass it as \`applicationContext: { accessibleApplicationRefs: ["application:<ref>"] }\`
-  on this **first** call. Without it, every command comes back
-  \`claimable: false\` (\`claimReason: "application_context_required_for_claim"\`)
-  even if you could otherwise claim it, and you'll need a second check-in
-  call with that same ref before \`nexarch_claim_command_by_id\` will work —
-  a wasted round trip when the application was knowable up front.
-- If you don't yet know the application, call check-in bare first. Each
-  returned command carries \`target_entity_key\` (e.g.
-  \`"application:veri_viva_platform_website"\`) — call check-in again with
-  that as \`accessibleApplicationRefs\` before trying to claim it.
+- If you have a **confirmed** application ref — returned by an earlier tool
+  call in this session (\`target_entity_key\` from a prior check-in,
+  \`nexarch_list_entities\`, \`nexarch_resolve_reference\`), or the human gave
+  you the exact ref — pass it as
+  \`applicationContext: { accessibleApplicationRefs: ["application:<ref>"] }\`
+  on this **first** call to skip a redundant round trip.
+- **Never guess the ref from a project/repo/directory name.** A repository
+  named \`veri-viva-platform\` does not mean its application ref is
+  \`application:veri_viva_platform\` — the real one might be
+  \`application:veri_viva_platform_website\` or anything else; projects and
+  applications are different entities with independently-chosen refs (see
+  the architecture-graph skill). A wrong-but-plausible-looking ref doesn't
+  just fail to claim — it silently filters real pending commands out of the
+  response, and check-in will wrongly report nothing pending. If you're not
+  certain a ref is correct, call check-in bare instead.
+- Calling bare (no \`applicationContext\`) is always safe and returns every
+  pending command's real \`target_entity_key\` — use that to make an
+  informed scoped call afterward.
+- If a scoped call's response includes a
+  \`pending_commands_outside_requested_scope\` warning, the ref you supplied
+  didn't match everything — it's very likely wrong. Re-call bare rather than
+  trusting the (incomplete) result.
 - Report exactly what check-in found. Don't reinterpret "check in" as
   registration (\`init-agent\`) or as a general health check
   (\`nexarch_get_governance_summary\`) — they're different actions.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nexarch",
-  "version": "0.12.34",
+  "version": "0.12.35",
   "description": "Your architecture workspace for AI delivery.",
   "keywords": [
     "nexarch",