@raidiant/notifai 11.0.3 → 11.0.5

package/dist/skill-source/manifest.json

@@ -1,16 +1,16 @@
 {
   "schema_version": 1,
-  "package_version": "11.0.3",
+  "package_version": "11.0.5",
   "skill": "notifai",
-  "digest": "sha256:380c49e6555eb44d06fdd92f3129050277ee21d04d2f9d42586fa2da906a4588",
+  "digest": "sha256:7ce9560daaf60cbe9d5186e4f46260e04acd13a7d1da3ddca3f5d0b8b031f567",
   "files": [
     {
       "path": "SKILL.md",
-      "sha256": "8d9b88e8b8e33e3bf3ff41cee8f8409dbeae30a844077dfc720266e152ee5a38"
+      "sha256": "a24c8341c75d42b3f0ce45cefd42fcfe414ca79ace4aa9dc408aa7ad85434bd9"
     },
     {
       "path": "references/harness-setup.md",
-      "sha256": "8b8f7feef8360caab00fe37dbf69e01aa1c39ce9ebaa434b9522b615d70c5fe5"
+      "sha256": "78f2c373ceb57e80f77851603cb5ea4f085e6cdceea20b8a82b4f7ccff61a6ed"
     }
   ]
 }

package/dist/skill-source/notifai/SKILL.md

@@ -305,8 +305,9 @@ user to run a command you could have run yourself.
 do not ask again. Run the send. If setup is missing, run `notifai init --json`
 and retry the exact send. Projectless requests never enable a Project.
 
-Flagless `notifai init --json` asks nothing and reaches delivery
-proof. Two independent decisions remain: Question Routing — devices or
+`notifai init --json` starts needed browser approval without a terminal prompt.
+Keep it running while the User approves.
+Two independent decisions remain: Question Routing — devices or
 terminal only — and the skill: this project or every project here.
 Lifecycle wiring has no scope: one install per harness for this machine;
 `notifai project enable` is the per-project switch. Never guess unattended:
@@ -328,7 +329,7 @@ its own exact-session admission check.
 
 Then gather the human-only steps its reported gap needs:
 
-- approving this machine in the browser (after **you** started `notifai login`)
+- approving this machine in the browser opened by `notifai init`
 - installing the companion app, signing in, and allowing notifications
 
 Never emulate User-owned actions, claim to approve hooks yourself, or claim an

package/dist/skill-source/notifai/references/harness-setup.md

@@ -14,7 +14,9 @@ diagnosing, or recovering — not before.
 
 ## Signing this machine in
 
-Run `notifai login` yourself. It opens a browser page only the user can approve.
+Run `notifai init --json` yourself. It starts machine approval when needed and
+opens a browser page only the User can approve. Keep the command running while
+they approve; its bounded progress is on stderr and final readiness is on stdout.
 
 In a headless or remote shell, `notifai login --no-open` prints the approval URL
 instead of trying to open a browser — hand the user that URL. `--name <name>`
@@ -29,8 +31,9 @@ either as broken.
 
 ## Install deliberately
 
-Flagless `notifai init --json` needs no answer and closes everything before
-this point. Hooks place files, so this is where a question belongs: ask whether
+Flagless `notifai init --json` asks no terminal questions and advances the
+required setup steps; its reported gap names any remaining User action. Hooks
+place files, so this is where a question belongs: ask whether
 they want questions routed. There is no scope to ask about — Notifai installs
 one lifecycle mechanism per harness, for this machine, and whether it acts in a
 project is `notifai project enable`. Never tell the user to run setup commands
@@ -97,6 +100,11 @@ foreground owner. Keep it alive for the complete answer window and set
 request ID, inspect the original with `notifai replies <request_id> --json` and
 `notifai status <request_id> --json`, and never send a duplicate.
 
+Conflicting inherited harness markers also require that foreground flow.
+Historical hook timestamps cannot prove which nested Agent Session owns a
+shell. Do not strip markers or borrow another Agent Session's identity to make
+`ask` pass; basic sending remains available without guessed Source Context.
+
 ## Activation by harness
 
 - **Claude Code:** run the installer if needed, start one fresh Agent Session,
@@ -138,6 +146,9 @@ request ID, inspect the original with `notifai replies <request_id> --json` and
   lookup fails or returns unusable data it also fails safe as a non-sending
   worker; only a proven parent Agent Session receives owner context. Explicit textual
   delegation promotes that worker through the same skill-and-guidance rule.
+  Each model request receives current guidance when the Project is enabled,
+  including after compaction. Disabled Projects add no context; enabling one
+  takes effect on a subsequent request in the same Agent Session.
   OpenCode has no locally proven exactly-once continuation after `session.idle`,
   so `notifai ask` fails closed instead of accepting an answer into a void.
   Use a blocking `notifai send --reply` question when its answer must return to

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@raidiant/notifai",
-  "version": "11.0.3",
+  "version": "11.0.5",
   "type": "module",
   "description": "Send native device notifications from agents and local programs",
   "bin": {
@@ -12,7 +12,7 @@
   ],
   "dependencies": {
     "@clack/prompts": "^1.7.0",
-    "@raidiant/notifai-protocol": "6.1.3",
+    "@raidiant/notifai-protocol": "6.1.5",
     "commander": "^14.0.0",
     "picocolors": "^1.1.1",
     "smol-toml": "^1.4.0"