hirify-cli 0.4.3 → 0.4.5

package/bin/hirify.js

@@ -271,14 +271,73 @@ const options = (args) => {
 const count = (v) => (typeof v === 'number' && Number.isFinite(v) ? v : null)
 
 const out = (data, text) => {
-  if (process.argv.includes('--json')) console.log(JSON.stringify(data, null, 2))
-  else text()
+  if (process.argv.includes('--json')) {
+    // --json hands over the whole envelope, so a `meta.notice` on it travels structured and
+    // untouched. The human notice below is only for text mode.
+    console.log(JSON.stringify(data, null, 2))
+    return
+  }
+  text()
+  printNotice(data?.meta?.notice)
+}
+
+/**
+ * Print a structured notice the server attached to a successful answer (`meta.notice`). The
+ * call still succeeded, so this comes after the useful result, not in place of it. The CLI
+ * shows the text the server wrote and reads nothing into the policy behind it: it knows the
+ * notice object, not what produced it. No notice, or one with no message, prints nothing.
+ */
+function printNotice(notice) {
+  const message = typeof notice?.message === 'string' ? notice.message.trim() : ''
+  if (!message) return
+  console.log(`\nNotice: ${message}`)
 }
 
 // Text our own server wrote for the agent to read: application rules, address rejections.
 // Passing it through beats paraphrasing, because paraphrasing drifts from the real rule.
 const serverMessage = (body) => (typeof body?.message === 'string' && body.message ? body.message : null)
 
+/**
+ * The one-line report for a policy restriction: a canonical 403 that names itself
+ * `access_restricted`. It is kept apart from the quota and rate-limit walls on purpose,
+ * because those clear on their own and this one does not. The CLI states what the server
+ * sent - the message it wrote, when the restriction lifts, where to ask for a review - and
+ * adds no rule of its own about why it was applied.
+ */
+function accessRestrictedMessage(body) {
+  const err = (body && typeof body.error === 'object' && body.error) || {}
+  const line = (v) => (typeof v === 'string' && v.trim() ? v.trim() : null)
+  const parts = [line(err.message) || line(body?.message) || 'access on this account is restricted (403).']
+  const until = line(err.restricted_until)
+  if (until) parts.push(`It stays in place until ${until}.`)
+  const appeal = line(err.appeal_url)
+  if (appeal) parts.push(`To ask us to look at it again: ${appeal}`)
+  return parts.join('\n        ')
+}
+
+/**
+ * The report for a blocking notice: a canonical 409 that names itself `action_required`.
+ * Unlike a `meta.notice` on a success, this one stands in place of the answer - the server is
+ * holding the result until the person confirms - so the CLI shows the text the server wrote and
+ * the one command that clears it, and reads nothing into the policy behind it. That command is
+ * the acknowledgement capability the server lists in its manifest, reached the same way as any
+ * other, so no route to it is written here. It carries the notice's own id and its first
+ * advertised action, both as the server sent them, so the printed line runs as it stands.
+ */
+function actionRequiredMessage(body) {
+  const notice = (body && typeof body.error === 'object' && body.error && typeof body.error.notice === 'object' && body.error.notice) || {}
+  const line = (v) => (typeof v === 'string' && v.trim() ? v.trim() : null)
+  const parts = [line(notice.message) || 'this needs your confirmation before it can go ahead (409).']
+
+  const id = line(notice.id)
+  const action = Array.isArray(notice.actions) ? notice.actions.map(line).find(Boolean) : null
+  const call = 'hirify api call security.notices.ack'
+  parts.push(id && action
+    ? `To continue, acknowledge this notice: ${call} --data '${JSON.stringify({ id, action })}'`
+    : `To continue, acknowledge this notice: ${call}`)
+  return parts.join('\n        ')
+}
+
 const b64url = (buf) => buf.toString('base64').replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
 const now = () => Math.floor(Date.now() / 1000)
 
@@ -384,6 +443,27 @@ async function api(path, { method = 'GET', payload = null, allow = [], raw = fal
     return { status: res.status, body, text }
   }
 
+  // A policy restriction is a canonical 403 that names itself `access_restricted`. It is not a
+  // used-up allowance and not a rate limit, and retrying cannot lift it: the CLI reports it once
+  // and never retries. Checked ahead of `allow` so a caller that reads its own 403s still cannot
+  // take this one for an ordinary refusal. The clone leaves the body readable for the paths below.
+  if (res.status === 403) {
+    const restriction = await res.clone().json().catch(() => null)
+    if (restriction?.error?.code === 'access_restricted') die(accessRestrictedMessage(restriction))
+  }
+
+  // A blocking notice is a canonical 409 that names itself `action_required`. Unlike a
+  // `meta.notice` on a success, it stands in place of the answer: the server is holding the
+  // result until the person acknowledges the notice, so the CLI reports it, exits unsuccessfully,
+  // and never retries - retrying cannot clear it. Checked ahead of `allow`, like the restriction
+  // above, so a caller that reads its own 409s cannot take this one for an ordinary conflict; a
+  // 409 without this code is left to the handling below, unchanged. The clone leaves the body
+  // readable for those paths.
+  if (res.status === 409) {
+    const blocked = await res.clone().json().catch(() => null)
+    if (blocked?.error?.code === 'action_required') die(actionRequiredMessage(blocked))
+  }
+
   if (allow.includes(res.status)) {
     return {
       status: res.status,
@@ -1516,7 +1596,8 @@ Where to apply
 
 Applying
   Most vacancies here came from somewhere else: company pages, Telegram channels, other
-  boards. For those, reveal brings back the address and the person applies themselves.
+  boards. For those, reveal brings back the address, and the application is made there rather
+  than through Hirify.
   Vacancies hosted on Hirify can be applied to from here:
 
     hirify profile list

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hirify-cli",
-  "version": "0.4.3",
+  "version": "0.4.5",
   "description": "Hirify CLI for AI agents: browser sign-in, job feeds, search, reading a vacancy in full, contacts to apply to, and applying on Hirify.",
   "bin": {
     "hirify": "bin/hirify.js"

package/skills/hirify/SKILL.md

@@ -75,8 +75,9 @@ the guide, it says so; then ask the user what to filter on.
 Two cases, two commands:
 
 - **Hosted on Hirify** -> `hirify vacancy apply <slug>` sends the application through Hirify.
-- **From somewhere else** -> `hirify vacancy reveal <slug>` gives the link or contact, and **the
-  user applies themselves**. `vacancy apply` refuses these and says so.
+- **From somewhere else** -> `hirify vacancy reveal <slug>` gives the link or contact, and the
+  application goes there rather than through Hirify. `vacancy apply` refuses these and says so.
+  What you do with that destination is between you and your user.
 
 - **Ask first, every time, and show what you are about to send.** An application cannot be taken
   back. Never apply to a list on a single "yes".

package/skills/hirify/reference.md

@@ -148,8 +148,8 @@ The last line before that says which way to apply:
 
 - `Apply on Hirify: hirify vacancy apply <slug>` - the vacancy is hosted here.
 - `Where to apply: hirify vacancy reveal <slug> (uses 1 reveal)` - it came from elsewhere, so the
-  user applies themselves. Take this from `vacancy read` rather than finding out from a refusal on
-  `vacancy apply`.
+  application goes to that destination rather than through Hirify. Take this from `vacancy read`
+  rather than finding out from a refusal on `vacancy apply`.
 
 Contacts, the apply destination and where the vacancy came from are never in this answer. That is
 what `vacancy reveal` is for.
@@ -199,8 +199,8 @@ Answers:
   where they choose to.
 - `there is no vacancy with that slug.`
 - a refusal in the server's own words, which covers archived, flagged, someone else's profile, and
-  **vacancies not hosted on Hirify**. For those, use `vacancy reveal` and let the user apply
-  themselves.
+  **vacancies not hosted on Hirify**. For those, use `vacancy reveal` and apply at the destination it
+  returns.
 - `the application could not be sent right now.` means our side failed, not the user's data.
 
 ## Saved searches and delivery