[dynamicheart]

Agents holding a confirmed personal key cannot discover its bot ID, and saved skills/tokens from other Lockbot implementations can be mistaken for this API. Add authenticated scope discovery and explicit service/skill metadata so a user can supply a skill URL, confirm enrollment in chat, and let the Agent discover its bot without scanning IDs.

Fixes #3

Behavior

• Add GET /api/agent/context: a valid personal key resolves only its bound bot, verified actor, enabled state and relative operation links. It works for stopped or suspended bots without granting resource access. Revoked, expired, deleted-bot and identity-invalid keys remain rejected. The route has ingress and shared per-key read limits.
• Extend the public skill manifest with a persistent instance ID, service ID lockbot.resource-api, API contract version, software version, skill identity and installable bundle. API responses advertise the current skill revision; Agents check at task start/reconnect and before their next mutation after a revision change.
• Publish lockbot-resource-agent and lockbot-operator-agent installation bundles. The skills identify the approved origin without sending credentials, keep credentials private and scoped to origin/instance/bot identity, and leave other platforms' skills/tokens intact. Personal and OP manifests advertise their own credential schemes; OP keys do not gain personal context/enrollment.
• Explain reading a shared SKILL.md URL for the current task versus installing it for ongoing use. Installation/reload uses client capabilities and existing user authorization. Unsupported clients reload the Markdown each task rather than claiming an installation succeeded.
• Preserve published request fields, HTTP statuses, string authentication detail, legacy download URLs, ZIP roots and manifest fields. Add top-level auth error codes and a context URL, distinguishing wrong-bot use without breaking the released 401 body type. No existing key requires rotation or rebinding for a skill update.

Compatibility and storage

The instance UUID occupies one entry in the existing site-settings table and survives normal restarts/upgrades. No resource state or credential scope is migrated. Older 2.10.0 servers retain the documented approved-bot configuration fallback; clients never scan IDs or try another platform's token/API. Public service identifiers prevent accidental confusion; the user-approved origin remains the credential destination boundary.

The public design note includes the acceptance checklist for discovery, compatibility, updates and coexistence. This PR is independent of the legacy state-file migration in PR #2.

Validation

• Full concurrent regression: 1149 passed, 5 skipped.
• Final targeted discovery/ingress/skill regression after the OP manifest review: 29 passed.
• Ruff lint and format checks; both packaged skills pass skill validation.
• Pre-deployment auth/discovery/skill regression: 103 passed.
• Live HTTP smoke: 18 checks passed, with both real group notifications visually verified.
• Tests cover enrollment without bot ID, NODE/DEVICE/QUEUE discovery, invalidation and wrong principal types, disabled/stopped bots, legacy and new ZIPs/hashes, skill changes/ETags/version headers, OpenAPI auth boundaries, read budgets and concurrent persistent instance initialization.

Deployed to the isolated nightly test service only; not merged or formally released. The existing production service is unchanged.

Live verification used an existing retained mock key to discover its bot without an ID, verified both ZIP downloads and hashes, checked the wrong-bot/invalid-key cases, acquired a free fictional resource with Agent/task metadata, then released it and verified task cleanup. Both operation notifications were confirmed in the authorized test group. A subsequent service restart preserved the instance ID, bot configurations and existing credentials. The chat authorization success message now omits the bot ID; it remains available to the Agent through context.