A personality belongs to a person

Owner's correction to 1.4.0: a model's character is per (model, person), and only
the description and the notes stay instance-wide. Two people talking to one model
are not talking to the same personality, and neither can see the other's.

The administrator's box becomes the DEFAULT, resolved by `personas.effective` as
a fallback and never as a layer -- two personalities at once contradict each
other with nothing to say which is losing, which is the reasoning behind "system
prompts replace, never stack". `persona_write` takes no argument naming a model
or a person; both come from the ToolContext, so it can only write the character
it has with whoever it is talking to, and it never touches the default.

Impressions move to their own table. Not a `kind` column: 1.4.0 shipped
`UNIQUE(model_key, owner_id)`, SQLite cannot alter a constraint and this schema
is additive-only, so a discriminator would leave an upgraded instance unable to
hold both rows for one pair. That leaves the first MANUAL_STEPS entry this
project has had -- the two shapes are indistinguishable, so nothing rewrites
them: a repair would be guessing at text that is read back in the first person.

TWO BUGS FROM A PHONE

`min-width` beats both `width` and `max-width` -- CSS clamps width to max-width
and then raises the result to min-width -- so `.canvas` and `.terminal` were
384px wide on every screen narrower than that, their `min(…, 100vw)` cap
overruled, and `.inspector` had no cap at all on a width that is a preference
draggable to 2400px. None of it scrolled sideways, because all three are
`position: fixed` and fixed overflow does not extend the scrollable area -- which
is exactly why the 1.1.0 narrow pass reported these pages clean. `min-width: 0`
in the overlay query, full width below the phone breakpoint, tablet column kept.

And the install button now says why it is absent. Measured against the live
instance: the manifest meets every Chrome criterion and the blocker is a
certificate from a private CA, so the origin is not trustworthy, the service
worker is refused and no install is offered. `base.html` had been swallowing that
with an empty catch -- which kept the page working, the reason it was there, and
threw away the only evidence. It now records the outcome and `app.js` turns it
into a sentence naming the certificate, which is the cause the old hint did not
mention.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-26 12:20:40 +00:00
co-authored by Claude Opus 5
parent df52ec9d96
commit ac51dd46cc
20 changed files with 1019 additions and 201 deletions
+20 -1
View File
@@ -36,7 +36,26 @@ log = logging.getLogger(__name__)
# Schema changes that this module cannot perform. Kept as documentation so a
# failure has somewhere to point rather than being a mystery.
MANUAL_STEPS: list[str] = []
MANUAL_STEPS: list[str] = [
# 1.4.0 stored "what a model makes of you" in `personas`, identified by
# `owner_id` being set. From 1.5.0 that same shape means "this person's own
# personality", and impressions live in `impressions`. Nothing rewrites them
# automatically: the two are indistinguishable by shape, so a repair would be
# guessing at somebody's text, and a personality is read back to the model in
# the first person. Only an instance that actually ran 1.4.0 -- released and
# superseded the same day -- can have any.
#
# INSERT INTO impressions (id, model_key, owner_id, content, author,
# enabled, created_at, updated_at)
# SELECT id, model_key, owner_id, content, author, enabled,
# created_at, updated_at
# FROM personas WHERE owner_id IS NOT NULL;
# DELETE FROM personas WHERE owner_id IS NOT NULL;
#
# Or simply delete them: nothing had time to write one worth keeping.
"personas written by 1.4.0 with an owner are impressions, not personalities "
"-- see the comment in db/migrations.py to move or remove them",
]
def _default_shape(column: Column) -> type | None:
+2 -1
View File
@@ -62,7 +62,7 @@ from lembas.db.models.library import (
SkillRevision,
chat_knowledge_bases,
)
from lembas.db.models.persona import Persona, PersonaRevision
from lembas.db.models.persona import Impression, Persona, PersonaRevision
from lembas.db.models.report import (
SOURCE_CHAT,
SOURCE_MANUAL,
@@ -178,6 +178,7 @@ __all__ = [
"ImageWorkflow",
"KnowledgeBase",
"McpServer",
"Impression",
"Memory",
"Persona",
"PersonaRevision",
+81 -28
View File
@@ -1,27 +1,43 @@
"""Who a model is, and what it has made of the person it is talking to.
"""Who a model is with one person, and what it makes of them.
Two different things, one table, and the discriminator is a column:
Both are per **(model, person)**: a model's character is something it develops
with somebody, so two people talking to the same model are not talking to the
same personality, and nobody on a shared instance inherits anybody else's.
`Model.description` and `Model.notes` remain the instance-wide facts about a
model -- those are what it *is*, not who it has become with you.
* ``owner_id IS NULL`` -- the model's **persona**. Instance-wide, seeded by an
administrator, and rewritten by the model itself when it is allowed to.
* ``owner_id`` set -- that model's **read of that person**, kept as it goes.
Per (model, person) rather than per model, because two models may honestly
arrive at different views of the same somebody, and on an instance with more
than one account nobody should inherit another person's reflection.
Two tables rather than one with a discriminator, and the reason is a constraint
rather than taste. 1.4.0 shipped `personas` with `UNIQUE(model_key, owner_id)`,
SQLite cannot alter a constraint, and this project's schema changes are additive
only -- so a `kind` column would have left an upgraded instance unable to hold
both a personality and an impression for one pair. A new table has no such
problem.
Why not a fourth prompt layer: because *"system prompts replace, never stack"*
is a decision this project has already taken. Both of these reach the model as
``{{persona}}`` and ``{{person_view}}``, through ordinary fragments, exactly the
way the memories block does.
* **Persona** -- the personality. `owner_id` set is that person's; `owner_id
IS NULL` is the **default** an administrator writes on the model's page, which
is what a person starts from before the model has written anything of its own.
* **Impression** -- what that model makes of that person. Always somebody's,
never instance-wide.
⚠ **``model_key`` is the model's text id, not the ``Model`` row's primary key**,
and there is deliberately no foreign key to ``models``. "Test & refresh" on the
connection screen deletes any model the endpoint no longer lists and recreates
it when it comes back -- so a row keyed on the primary key would lose a model's
whole personality to a refresh taken while its endpoint happened to be loading
something else. This is the reasoning ``Chat.model_id`` already carries: the
text id survives, and a row naming a model that no longer exists is invisible
rather than broken.
Why neither is a fourth prompt layer: *"system prompts replace, never stack"* is
a decision this project has already taken. Both reach the model as `{{persona}}`
and `{{person_view}}`, through ordinary fragments, the way the memories block
does.
⚠ **`model_key` is the model's text id, not the `Model` row's primary key**, and
there is deliberately no foreign key to `models`. "Test & refresh" deletes any
model the endpoint no longer lists and recreates it when it comes back -- so a row
keyed on the primary key would lose a model's whole personality to a refresh
taken while its endpoint happened to be loading something else. This is the
reasoning `Chat.model_id` already carries: the text id survives, and a row naming
a model that no longer exists is invisible rather than broken.
🚨 **An instance that ran 1.4.0 holds impressions in `personas`.** That release
stored them there, keyed by `owner_id` being set -- which is now what a person's
own *personality* means. They read as personalities rather than as impressions.
It is one SQL statement to move or remove them and it is recorded in
`db/migrations.MANUAL_STEPS`; nothing rewrites them automatically, because a
repair that cannot tell the two apart would be guessing at somebody's data.
"""
from __future__ import annotations
@@ -34,7 +50,7 @@ from lembas.db.models.library import AUTHOR_MODEL, AUTHOR_USER
class Persona(UUIDPrimaryKey, Timestamps, Base):
"""One model's personality, or one model's read of one person."""
"""One model's personality: a person's own, or the default they start from."""
__tablename__ = "personas"
__table_args__ = (UniqueConstraint("model_key", "owner_id"),)
@@ -42,8 +58,8 @@ class Persona(UUIDPrimaryKey, Timestamps, Base):
# The model's `model_id`, not a `models.id`. See the module docstring.
model_key: Mapped[str] = mapped_column(String(300), nullable=False, index=True)
# NULL means "this is the model's own persona". Set means "this is what that
# model makes of this person".
# Whose personality this is. NULL is the **default** an administrator writes,
# used until the model has written something of its own with somebody.
owner_id: Mapped[str | None] = mapped_column(
String(32), ForeignKey("users.id", ondelete="CASCADE"), nullable=True, index=True
)
@@ -63,12 +79,13 @@ class Persona(UUIDPrimaryKey, Timestamps, Base):
)
@property
def is_reflection(self) -> bool:
return self.owner_id is not None
def is_default(self) -> bool:
"""Whether this is the administrator's seed rather than somebody's own."""
return self.owner_id is None
def __repr__(self) -> str:
kind = "reflection" if self.is_reflection else "persona"
return f"<Persona {kind} {self.model_key} {self.content[:30]!r}>"
whose = "default" if self.is_default else self.owner_id
return f"<Persona {self.model_key} {whose} {self.content[:30]!r}>"
class PersonaRevision(UUIDPrimaryKey, Timestamps, Base):
@@ -93,4 +110,40 @@ class PersonaRevision(UUIDPrimaryKey, Timestamps, Base):
persona: Mapped[Persona] = relationship(back_populates="revisions")
__all__ = ["AUTHOR_MODEL", "AUTHOR_USER", "Persona", "PersonaRevision"]
class Impression(UUIDPrimaryKey, Timestamps, Base):
"""What one model makes of one person, in its own words.
Always somebody's: there is no instance-wide impression, because the whole
point of it is that it is about a particular person. `owner_id` is therefore
NOT NULL, which is the one structural difference from `Persona` and is worth
having -- a row here with nobody attached could only be a bug.
No revision history, deliberately, where a persona has one. A personality is
a document a model might wreck and want back; an impression is a standing
opinion that is *supposed* to change as it learns, and a history of every
version of it would be a log of somebody being reassessed. The person can
read it and delete it, which is the control that matters here.
"""
__tablename__ = "impressions"
__table_args__ = (UniqueConstraint("model_key", "owner_id"),)
model_key: Mapped[str] = mapped_column(String(300), nullable=False, index=True)
owner_id: Mapped[str] = mapped_column(
String(32), ForeignKey("users.id", ondelete="CASCADE"), nullable=False, index=True
)
content: Mapped[str] = mapped_column(Text, default="")
author: Mapped[str] = mapped_column(String(16), default=AUTHOR_MODEL, nullable=False)
enabled: Mapped[bool] = mapped_column(Boolean, default=True, nullable=False)
def __repr__(self) -> str:
return f"<Impression {self.model_key} {self.owner_id} {self.content[:30]!r}>"
__all__ = [
"AUTHOR_MODEL",
"AUTHOR_USER",
"Impression",
"Persona",
"PersonaRevision",
]