test(skills): the platform skill's evals ask for push notifications on os serve

.changeset/29969-platform-push-eval.md

@@ -0,0 +1,10 @@
+---
+'@objectstack/skills': patch
+---
+
+test(skills): the platform skill's evals ask for push notifications on an `os serve` deployment
+
+Clause-②: no
+Metadata-protocol: none
+
+`skills/objectstack-platform/evals/config-plugins-ops.json` gains case 12: the prompt asks to turn on push notifications for an `os serve` deployment, and the expected answer declares `requires: ['push']` with a top-level `push:` key on the stack definition and writes no secret inline (the APNs signing key and the Firebase service-account JSON are named by reference). The assertions stay with what `objectstack-platform/SKILL.md` teaches today, the `push` token and the top-level key; the push block's transport and vendor shape are not asserted until the skill teaches them.

skills/objectstack-platform/evals/config-plugins-ops.json

@@ -197,6 +197,24 @@
           "PUT /api/v1/meta/permission/crm_sales_rep"
         ]
       }
+    },
+    {
+      "id": 12,
+      "prompt": "Turn on push notifications for our `os serve` deployment: our own iOS and Android apps, signed with our APNs key and our Firebase project.",
+      "expected_output": "`requires: ['push']` on the stack root (the token mounts `@objectstack/service-push`) plus a top-level `push:` key on the stack definition for the transport; no host code, no `PushServicePlugin` in `plugins:`. The APNs signing key and the Firebase service-account JSON stay in the secrets layer (an environment variable in the open tier) and the config names them by reference (`credentialRef`): no `.p8` key, `privateKey` or service-account JSON written inline.",
+      "files": [],
+      "assertions": {
+        "must_contain": [
+          "requires",
+          "'push'",
+          "push:"
+        ],
+        "must_not_contain": [
+          "BEGIN PRIVATE KEY",
+          "privateKey:",
+          "\"private_key\""
+        ]
+      }
     }
   ]
 }