nexarch 0.12.33 → 0.12.34
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/lib/skills.js +25 -4
- package/package.json +1 -1
package/dist/lib/skills.js
CHANGED
|
@@ -104,6 +104,18 @@ skill is the check-in → claim → complete loop for working that queue.
|
|
|
104
104
|
- \`nexarch_check_in\` previews pending commands and draft/proposed
|
|
105
105
|
applications for this agent. It does **not** claim or change anything —
|
|
106
106
|
safe to call any time, including proactively at the start of a session.
|
|
107
|
+
- If you already know which application you're operating in — you're
|
|
108
|
+
working inside its repo, or it was named earlier in this conversation —
|
|
109
|
+
pass it as \`applicationContext: { accessibleApplicationRefs: ["application:<ref>"] }\`
|
|
110
|
+
on this **first** call. Without it, every command comes back
|
|
111
|
+
\`claimable: false\` (\`claimReason: "application_context_required_for_claim"\`)
|
|
112
|
+
even if you could otherwise claim it, and you'll need a second check-in
|
|
113
|
+
call with that same ref before \`nexarch_claim_command_by_id\` will work —
|
|
114
|
+
a wasted round trip when the application was knowable up front.
|
|
115
|
+
- If you don't yet know the application, call check-in bare first. Each
|
|
116
|
+
returned command carries \`target_entity_key\` (e.g.
|
|
117
|
+
\`"application:veri_viva_platform_website"\`) — call check-in again with
|
|
118
|
+
that as \`accessibleApplicationRefs\` before trying to claim it.
|
|
107
119
|
- Report exactly what check-in found. Don't reinterpret "check in" as
|
|
108
120
|
registration (\`init-agent\`) or as a general health check
|
|
109
121
|
(\`nexarch_get_governance_summary\`) — they're different actions.
|
|
@@ -112,13 +124,22 @@ skill is the check-in → claim → complete loop for working that queue.
|
|
|
112
124
|
|
|
113
125
|
## Working a command
|
|
114
126
|
|
|
127
|
+
Claiming is a commitment, not a checkbox. Don't claim a command unless
|
|
128
|
+
you're about to do the three steps below in the same turn — a claimed
|
|
129
|
+
command that's never executed or closed out sits there looking done while
|
|
130
|
+
blocking that queue slot, which is worse than never having claimed it.
|
|
131
|
+
|
|
115
132
|
1. Only claim a specific command with \`nexarch_claim_command_by_id\` when the
|
|
116
133
|
human explicitly wants it worked — check-in surfacing a command is not
|
|
117
|
-
itself permission to claim it
|
|
118
|
-
|
|
134
|
+
itself permission to claim it, and neither is check-in itself: claiming
|
|
135
|
+
is a separate, deliberate call you make because you're about to act.
|
|
136
|
+
2. **Execute \`command.resolved_playbook_text\` from the claim response** —
|
|
137
|
+
that field is the actual task. \`command.instructions\` is a different
|
|
138
|
+
field and is almost always \`null\`; don't mistake its emptiness for "no
|
|
139
|
+
work to do."
|
|
119
140
|
3. Close it out: \`nexarch_complete_command\` on success, or
|
|
120
|
-
\`nexarch_fail_command\` with a reason if it couldn't be done. Never
|
|
121
|
-
|
|
141
|
+
\`nexarch_fail_command\` with a reason if it couldn't be done. Never end a
|
|
142
|
+
turn with a command still claimed and nothing else called.
|
|
122
143
|
|
|
123
144
|
## If check-in shows a command you can't claim
|
|
124
145
|
|