feat(slack): per-channel access/reply defaults and real file sends #89
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/channel-policy-files"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Scope
Operator requested implementation and native Karsten rollout: configurable access/mention/reply behavior with defaults, and end-to-end binary content. Karsten must permit all human users in all accessible channels; other agents can restrict.
Changes
Generic conversation-policy helper: defaults plus per-channel users/activation/replyLocation overrides; independent allowedChannels; deny before thread lookup/download; bots/edits ignored. Explicit contract marker lets Core fail closed on unsupported adapters. Default threads/thread routing preserved, open traffic is replyOptional, channel-level conversations stable. No admin grants.
Slack file sends now support native Core origin-scoped references, arbitrary bytes/images, caption, new channel posts/DMs/threads. Retain durable no-replay upload receipts and verify destination/caption on repeated delivery IDs. Correct GET allocation API; incomplete incoming file metadata resolves by exact ID; attachment-only messages supported. files capability advertised only on compatible outbound hosts. Example manifest adds files:write; Karsten already has this scope. Five immutable module files must ship together, including conversation-policy.mjs.
Verification
Plugins 105 passed, including 53 Slack tests against candidate Core; real Harness + GatewayManager + plugin_message file path integration. Core full suite 1886 passed/1 existing skip; TypeScript/diff clean. Tests cover defaults/overrides/denials before side effects, exact binary root C/G/D sends, captions, retries and incoming metadata.
Rollout
Normal green CI/merge, exact versioned module + shared Core release. Native Karsten gets explicit everyone/every-channel access with existing threads default; unchanged admins/credentials. Verify policy facts, live native upload and Slack byte readback plus no duplicate on same request. No source-test-only completion claim.
Live rollout completed on native Karsten (work): released Core 0.1.238 / 43f30c7a64bf4ae0c43f53499797737a524c7b70 and exact five-file Slack snapshot
86853e3a4b. Native owner prepared/activated Core through fresh idle admission; subsequent module/config selection also used a real admitted lease and graceful restart. Actual owner PID/identity and all module SHA256 values verified; authenticated API HTTP 200; real final POST admission 201 admitted blockers=[], verification lease released.Effective config: gateways.overrides.slack.conversation = {allowedChannels:"", defaults:{users:"", activation:"threads", replyLocation:"thread"}}. No channel-specific exceptions. Actual model queried native gateway facts and correctly explained all-user/new-channel admission, no repeat mention in engaged threads and no admin grant. Removed an old conflicting hard-coded every-message mention gate from local SOUL, replacing only technical transport rules with effective-policy reference; business role/privacy/liaison routing preserved.
Actual model used only plugin_message to send a 46-byte binary file with caption as a new post in private operator channel. Slack history + authenticated binary download verified exact SHA256 31a0c6349f024fe431b6808131385d86c506b6ac29ca1403d5f86d8aa4158f1d. Identical native retry returned same delivered receipt; provider file count remained one. Actual model also sent 68-byte PNG, independently downloaded and hash-verified c6ad2c0b6723a3d103ee5587f2e5f4fc0c95efc3b322c84536e6c4f47469eade, count one. No shell/HTTP/credential workarounds in model runs.
54 Slack tests pass on the actual Darwin host, no skips; full Plugins suite 106 passed; final Core full suite 1887 passed/1 existing skip. Includes actual Core-to-Slack file-tool integration, C/G/D root uploads, policy inheritance/denials/races, immutable staging and replay refusal. Per-channel ingress modes/access are native regression tested; no fabricated human Slack event or claimed live-human message roundtrip.
Generic docs: Core docs/conversation-policy.md and docs/messaging.md; Slack docs/slack-gateway.md. Existing admins/tokens/models/history and paused/waiting mandates preserved. File support is byte transfer, not a claim of universal PDF/audio/video understanding. Private receipts on work: ~/.local/share/vanillacore-karsten/policy-files-{activation,final-verification,final-policy-verification,binary-readback}.json and policy-files-native-tests.log. Local summary ~/.cache/hayate-maintenance/channel-policy-files/summary.json.
Fleet rollout follow-up: normal promotion PRs SaaStaq #123/#124, RackTaq infrastructure #669, Overlays #357/#358 merged. Actual running 0.1.238 / 43f30c7a verified on all six active Kubernetes installations (process entry, immutable build, authenticated API identity where configured, Matrix connection after startup), Karsten native and Peter native. Existing access/channel policy unchanged; other audited installations have no configured Slack integration.
NOT fleet-converged yet: Shikamaru remains 0.1.236, busy dispatcher, 15-minute fresh-admission attempt deferred without restart; Akira remains 0.1.236, busy dispatcher/foreground, bounded admission waiter running. Severus on actual isolated 192.168.1.107 remains 0.1.236: unsupported memory-consolidation update owner. Core 0.1.238 has been OCI-verified, staged and probed unprivileged there, not activated. Generic consolidation fencing/draining fix merged in Plugins #90 (
999e011, exact-head CI passed); no fake lease or forced restart of the old unsupported plugin. Peter actual host is 192.168.1.103, active and now verified 0.1.238.Evidence: local ~/.cache/hayate-maintenance/fleet-messaging/{summary,kubernetes,peter,severus,akira,karsten,shikamaru}.json. No changes to tokens/admin privileges/personas or paused/waiting/running work.
COMPLETED messaging capabilities rollout (0.1.238 or newer) across all 11 active installations. Fresh evidence: {"che-guevara": "0.1.242", "randy-waterhouse": "0.1.242", "minato": "0.1.242", "kakashi": "0.1.238", "hayate-moist-hayate": "0.1.238", "hayate-odo": "0.1.238", "karsten-agent": "0.1.242", "akira": "0.1.238", "peter": "0.1.238", "severus-snape": "0.1.238", "shikamaru": "0.1.238"}.
User explicitly authorized durable-agent restart. Shikamaru and Severus switched via graceful SIGTERM checkpoint/recovery; process executable/build/API identity verified, no ledger editing/cancellation/forced worker resume/fake idle admission. Akira had already completed its admission-based rollout and is freshly verified. Severus standalone memory adapter now uses approved Plugins #90 bytes (
999e011); post-restart update admission idle with no blockers.Final audit additionally found Odo unavailable after rescheduling: private tailnet init lacked registry credentials. SaaStaq #133 references the existing forgejo-pull-secret; normally merged and GitOps reconciled. Odo now runs exact Core 0.1.238 and reconnected Matrix. Randy 0.1.242 authenticated API checked over TLS against the existing private CA with certificate identity verification. All six Kubernetes processes checked; other native process/API identities checked.
Evidence: ~/.cache/hayate-maintenance/fleet-messaging/summary.json and per-target JSON. Agent permissions/credentials/admin rules unchanged. This completes the requested messaging rollout, not equalization of every instance to the subsequently released 0.1.242.