60 lines
3.5 KiB
Markdown
60 lines
3.5 KiB
Markdown
# 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.
|