2 Commits

Include renames

Author	SHA1	Message	Date
HomerandClaude Opus 5	ac51dd46cc	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>	2026-09-26 12:20:40 +00:00
HomerandClaude Opus 5	df52ec9d96	Models that know about each other, and have a self ... Three features sharing one idea: a model here started from nothing every conversation and had no notion that anything else existed. THE ROSTER. `chat.roster_block` builds one line per model this *person* can reach -- through `permissions.models_visible_to`, never the table -- and `{{model_roster}}` carries it, gated on the `friend` family for the reason the memories block is gated on `memory`: a list of peers a model cannot talk to is context spent on nothing, and one checkbox is then the whole switch. New `Model.notes` column, a column and not a `capabilities_json` key for the reason `context_length` and `reasoning_efforts` both carry. ASKING A FRIEND. A second entry point in `services/subagent.py` rather than a second module, so one place still owns the bounds and the lifecycle. `_create_ child` takes the friend's (model_id, connection_id) *pair*, because Model is unique on both and an id alone does not say which endpoint. Three things differ from a helper: the effort is the friend's own default and never the parent's (the 1.3.0 bug by another door -- the vocabularies differ and a level a model does not take raises inside its chat template), the chat is ordinary even when the asker's is an agent chat, and `scope_json["role"]` marks it so `core.friend` speaks instead of `core.subagent`. `friend` joins the unattended withdrawal set: a friend that could ask a friend is the same unbounded fan-out in politer clothes. Budget, concurrency and quota are shared with helpers, so one reply cannot spend the allowance twice. PERSONALITY. One table, two roles, `owner_id IS NULL` the discriminator: the model's own persona, and its read of one person. Keyed on the model's *text* id with no foreign key, because "Test & refresh" deletes a model the endpoint has stopped listing and a personality must not be collateral. `PersonaRevision` copies SkillRevision, and so does the argument: the safety story for a model rewriting itself is a record and a way back, not a gate. The reflection is shown to the person it is about, in their own settings, which is the whole of why keeping one is acceptable. `persona` is withdrawn from any unattended chat -- a helper's task, a friend's question and a schedule's instruction are all words nobody watched being written. Two bugs found while reading for this, both silent: `review_model_id` stored a `Model` primary key, so a refresh taken while an endpoint was not listing that model unset the administrator's choice -- and `_reviewer` then fell back to the chat's own model, so pictures were judged by a model nobody chose. Now the text id, with the primary key still accepted. `_messages_after` used a bare `>` on `created_at`, so a row sharing the edited turn's microsecond survived a rewind -- and `_send` writes a user turn and its placeholder back to back, which is exactly that tie. Deliberately NOT `thread_tail`'s `(created_at, id)` tiebreak: ids are random UUIDs, so that settles a tie by coin toss. A tie now reads as "later", which is the safe direction for an operation whose purpose is to discard what follows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-26 02:04:55 +00:00