Collaborative operation server: teammates, membership, presence, tasks, and event stream #13

New issue

Open

opened 2026-08-16 05:19:41 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 05:19:41 +00:00

(Migrated from github.com)

Problem

Hackmode has a local operation model but no collaborative runtime for multiple investigators. Adding collaboration directly to the local operation classes without reusing StarIntel auth/events would duplicate server infrastructure and make synchronization brittle.

Current behavior

Hackmode owns local-first operation state and a Tek9 operation store.
starintel-server already owns authenticated user records, principal types, scopes, password/session lifecycle, and credential storage.
starintel-server also has a durable actor-event contract with validation, idempotent CouchDB persistence, retry, dead-letter/quarantine, trace IDs, and generation metadata.
No existing Hackmode teammate/presence/membership subsystem was found in the inspected code.

Desired behavior

Add a Hackmode collaboration/server subsystem centered on shared operations without creating another identity/event stack.

Initial capabilities:

operation membership and roles
teammate presence/heartbeat
shared operation metadata/status
task assignment/status
investigator notes/findings/artifact references
operation event stream
actor/message ownership attribution
synchronization with local operation stores and StarIntel ingest

Architecture

Start with useful actors, not dozens of empty classes:

HackmodeServer
-> OperationSupervisor
-> shared Operation session
-> Membership/Presence actor
-> Task registry actor
-> Operation event bridge
-> StarIntel synchronization bridge

Reuse StarIntel principals/users for remote identity and the StarIntel actor-event shape where it fits. Hackmode operation events should retain operation, principal/actor, event type, source id, trace id, timestamp, and provenance.

Local operation state remains usable offline. Collaboration is an enhancement, not a dependency for opening or running a local operation.

Protocol

Define protocol messages before HTTP/UI endpoints, e.g.:

join/leave operation
heartbeat/presence
assign/update task
append operation event
append note/finding reference
subscribe operation events
operation snapshot/status

Transport can then expose the same protocol over local Lisp calls and a server boundary.

Dependencies

#6 canonical operation/asset protocol
#9 executable Common Lisp tests
#12 persistent outbox for offline server synchronization
StarIntel auth/event APIs; extend starintel-server only if a missing primitive is proven

Acceptance criteria

two principals can join the same operation and observe membership
presence expires without deleting membership
task assignment and status changes are durable and attributed
event ordering has a documented per-operation guarantee
operation events include actor/principal identity and provenance
local operation remains usable with collaboration server unavailable
reconnect/sync is idempotent
malformed collaboration events are inspectable/quarantined
no duplicate user/password database is created in Hackmode

Verification

Use deterministic in-memory/fake transports first:

two investigators join
presence heartbeat/expiry
assign/reassign/complete task
concurrent event append
server unavailable while local operation changes continue
reconnect and replay without duplicate events
unauthorized membership/task mutation rejected at server boundary

## Problem Hackmode has a local operation model but no collaborative runtime for multiple investigators. Adding collaboration directly to the local operation classes without reusing StarIntel auth/events would duplicate server infrastructure and make synchronization brittle. ## Current behavior - Hackmode owns local-first operation state and a Tek9 operation store. - `starintel-server` already owns authenticated user records, principal types, scopes, password/session lifecycle, and credential storage. - `starintel-server` also has a durable actor-event contract with validation, idempotent CouchDB persistence, retry, dead-letter/quarantine, trace IDs, and generation metadata. - No existing Hackmode teammate/presence/membership subsystem was found in the inspected code. ## Desired behavior Add a Hackmode collaboration/server subsystem centered on shared operations without creating another identity/event stack. Initial capabilities: - operation membership and roles - teammate presence/heartbeat - shared operation metadata/status - task assignment/status - investigator notes/findings/artifact references - operation event stream - actor/message ownership attribution - synchronization with local operation stores and StarIntel ingest ## Architecture Start with useful actors, not dozens of empty classes: `HackmodeServer` ` -> OperationSupervisor` ` -> shared Operation session` ` -> Membership/Presence actor` ` -> Task registry actor` ` -> Operation event bridge` ` -> StarIntel synchronization bridge` Reuse StarIntel principals/users for remote identity and the StarIntel actor-event shape where it fits. Hackmode operation events should retain `operation`, `principal/actor`, `event type`, `source id`, `trace id`, timestamp, and provenance. Local operation state remains usable offline. Collaboration is an enhancement, not a dependency for opening or running a local operation. ## Protocol Define protocol messages before HTTP/UI endpoints, e.g.: - join/leave operation - heartbeat/presence - assign/update task - append operation event - append note/finding reference - subscribe operation events - operation snapshot/status Transport can then expose the same protocol over local Lisp calls and a server boundary. ## Dependencies - #6 canonical operation/asset protocol - #9 executable Common Lisp tests - #12 persistent outbox for offline server synchronization - StarIntel auth/event APIs; extend `starintel-server` only if a missing primitive is proven ## Acceptance criteria - two principals can join the same operation and observe membership - presence expires without deleting membership - task assignment and status changes are durable and attributed - event ordering has a documented per-operation guarantee - operation events include actor/principal identity and provenance - local operation remains usable with collaboration server unavailable - reconnect/sync is idempotent - malformed collaboration events are inspectable/quarantined - no duplicate user/password database is created in Hackmode ## Verification Use deterministic in-memory/fake transports first: 1. two investigators join 2. presence heartbeat/expiry 3. assign/reassign/complete task 4. concurrent event append 5. server unavailable while local operation changes continue 6. reconnect and replay without duplicate events 7. unauthorized membership/task mutation rejected at server boundary