DSH Dafeiyu Progression: Memory, Feeding & Saves

If Dafeiyu starts as a stranger every time, it is only a status skin. “Raising a fish” requires continuity: names and interactions persist, completed work produces rewards, relationships evolve, and the same character survives Session changes, plugin upgrades, and device migration.

Progression can also go wrong. Tying affinity directly to token consumption rewards waste; retaining every conversation forever creates unnecessary privacy risk.

Separate three data layers

Settings include position, size, volume, language, reduced motion, and visibility. They are low sensitivity and change frequently.

Progression includes name, food inventory, affinity, relationship level, unlocked motion, last interaction, and streaks. It represents game progress without requiring full conversations.

Memory includes explicit user facts, relationships, preferences, important events, whispers, and diaries. It is the most sensitive layer and must be viewable, editable, deletable, exportable, and fully resettable.

Separation lets users reset layout without losing relationships or delete private memory while keeping unlocked animations.

Reward completed value, not consumption

Good inputs include a completed DSH turn, confirmed task or Todo completion, explicit petting or feeding, capped daily use, a first successful tool category, and manual user praise.

Do not reward token count, output length, retries, Subagent count, or loop rounds. Those metrics turn waste into progress.

Make events idempotent

Reconnects, replay, and multiple clients may deliver the same completion more than once. Assign each reward a stable identity:

reward:<session-id>:<turn-id>:completed

Check before settlement so a page refresh cannot duplicate food. The Host owns the authoritative balance; clients do not mutate it directly.

Relationships need more than one number

Track long-term familiarity, short-term mood, energy controlling initiative, explicit trust milestones, and relationship stages requiring multiple conditions. Avoid punitive decay after one day away and avoid sudden intimacy caused by heavy token use.

Memory needs provenance and time

A durable memory should identify its text, source, creation and update times, scope, and sensitivity. Model inference must not become user fact. Keep character diary and imagination separate from user-confirmed memory so fictional reflections do not alter later Agent decisions.

Cross-Session and cross-device identity

Character identity belongs to a user or Profile, not one Session. Sessions supply events and context; Host-owned storage maintains progression.

Exports need a schema version and timestamp. Validate before import, back up current state, and replace transactionally. Every new version needs migration from older saves; unknown fields should be preserved or reported rather than silently erased.

Local-first persistence

Store data in the user-data directory, not the plugin package, repository, or Workspace. Use temporary files plus atomic replacement and keep a backup. Validate the primary file after crashes before falling back.

Exports may contain private relationships and history. Cloud sync requires separate authentication, encryption, deletion, and conflict resolution and must never hide inside an ordinary plugin update.

Constrain initiative

Proactive speech needs an off switch, hourly and daily caps, focus periods, a distinction between local scripted lines and generated text, visible cost, and deletion controls. dsh-fishtank demonstrates whispers, reflections, and portable JSON; dsh-pet demonstrates food, affinity, and work-round rewards.

Acceptance checklist

settings, progression, and memory are separate;
reward events are idempotent and capped;
token waste is never rewarded;
inference, diary, and confirmed facts remain distinct;
memory is viewable, editable, deletable, and exportable;
save formats are versioned and migratable;
writes are atomic with backups;
proactive speech is optional and capped;
one identity spans Sessions;
uninstall and reinstall retention is documented.

Build the plugin skeleton first, then connect Session and Tool Call events.