Add social feed, cooperative parties, guild goals, and operations recovery

2026-09-22 17:43:07 -04:00
parent 5bee808492
commit 46935c791e
17 changed files with 477 additions and 12 deletions
@@ -0,0 +1,59 @@
+# Community and operations
+
+## Live social behavior
+
+The Social Life page shows the last 250 confirmed conversations, relationship
+changes, invitations, departures, and guild actions. Pending requests and failed
+native receipts are distinct from completed activity.
+
+A scheduler checks fresh (under 90 seconds) world observations every 30 seconds.
+Party partners must be nearby, same faction, within ten levels, and interested
+in questing/exploring. Both characters decide using sociability and their directed
+trust scores. Negative trust rejects the invitation. Guild recruitment requires
+mutual trust of at least 3, an online bot guild leader, and a guildless candidate.
+Characters never abandon an existing guild merely to fill a recruitment target.
+Each participant gets ten minutes between proposals. Bot-only parties remain at
+five members or fewer; native commands refuse to modify human parties or raids.
+A resident may depart after ten minutes apart from all party companions.
+
+Native receipts verify membership. Accepted parties grant +1 reciprocal trust.
+Confirmed conversations grant +1, shared completed quests +3, and helping attack
+the same enemy +1 (combat help is throttled per pair to five minutes). Trust is
+bounded to -100..100. Replayed evidence cannot grant repeated credit within the
+bounded evidence window. Memories and relationship lists retain at most 100 rows
+per resident; dead/retired identities are not candidates for new activities.
+
+Observed guilds receive an editable shared goal: quest together, support allies,
+or explore other maps. The guild goal enters high-level decision context.
+Progress uses observed cooperative quests, shared combat, or map changes (once
+per member/map/day). Guild creation and forced cross-guild transfers are excluded.
+
+## Health, retention and recovery
+
+System Health displays Ubuntu and Windows samples with explicit stale markers,
+CPU, available memory, free disk, application database/log sizes, and model health.
+Possible stalled bots are those stationary for ten minutes while intending to
+quest/explore, with fresh noncombat observations. No automatic teleport is used.
+
+The operations agent prunes acknowledged game transport at one day, as the relay
+already does. Archived snapshots and terminal application commands use the chosen
+3–30 day retention (default 7). Pending work, memories, guild goals, relationship
+state and memorials are preserved. Current application log files rotate at 10 MB
+with three copies. Database files may retain freed SQLite pages for reuse.
+
+Install `deploy/playable/install-user-recovery.py` as the realm owner. It registers
+`azerothai-runtime.service` with Restart=always and a minute operations timer in
+the user's systemd manager. Enable user lingering for reboot startup. Telemetry
+uses the realm owner's existing docker group, including in older user sessions.
+Existing system relay/autonomy services remain owned by the system manager.
+
+`deploy/playable/windows-recovery.ps1` checks the local model and SSH tunnel every
+minute and sends Windows readings through SSH (no API token stored on Windows).
+The scheduled task runs at Windows logon. If local script execution is disabled,
+leave the task disabled until the user permits locally authored scripts; do not
+bypass a managed execution policy. This does not start VMware or log into Windows.
+The VM and PC still need to be running.
+
+Tests: `node scripts/test-core.mjs`, TypeScript checking, and the production build.
+Native commands verify identity, availability and permissions again at delivery.
+A database snapshot should be taken before the first deployment.