Repository navigation
feat(neopi): synchronize session model-role and advisor configuration #113
Description
Note
GPT-6 Astra on behalf of PsychedelicShayna
Contract
NeoCode and the NeoPi terminal must address the same authoritative native session. Model-role and advisor configuration belongs to NeoPi. NeoCode presents that state and sends explicit operations to its owner; it must not maintain a competing configuration or launch another writer.
This is a bounded configuration-parity issue under #49, not a decision on its generic menu-conversion mechanism. It does not introduce a core daemon or authorize access to the Captain's live database/wallet. #48 now records the boundary between private restoration proof and a human-approved real-profile run.
Current RPC/control inventory
Source snapshots: NeoPi nightly 0135e95e8f42442ae712d74a4ddc57bfb7b920d3; NeoCode nightly 02c938c281383c1a9ad21e001c76cef1d15ece60. These are source observations, not claims that every command was exercised against the installed binary. The earlier complete menu inventory remains useful but predates this snapshot.
| Area | NeoPi exposes today | NeoCode today / remaining need |
|---|---|---|
| Session identity | get_state includes native identity, model, thinking level and active role. Control uses the same session and role tracker. |
Restoration and ctl pipe attachment exist. Missing: a per-thread view of the connected configuration, rather than a provider-wide probe. |
| Model roles | get_roles: aliases, names, configured selectors, fallback patterns, resolved model/effort, hidden state. set_role selects through NeoPi's resolver and rejects busy/unresolved selections. |
Role aliases already appear in the picker; owned-session selection calls set_role. This is selection, not definition editing. Present chains/resolution without duplicating their resolver. |
| Model and effort | get_available_models, set_model, cycle_model, get_available_thinking_levels, set_thinking_level, cycle_thinking_level. |
Model/effort selection exists. Attached-runtime mutation guards and idle-event filtering mean synchronized configuration is not complete. A payload-free model_changed needs a fresh state read. |
| Role definitions | Control settings_get/set/unset addresses registered settings, including modelRoles members. |
No dedicated JSON-line role-definition CRUD API. Do not assume declared scopes are implemented: the control handler does not consume read/layer, and a modelRoles member uses the special setter even with runtime scope. Editing needs an explicit authoritative persistence contract. |
| Advisor settings | Registry exposes advisor.enabled, syncBacklog, reviewMode, reviewInterval, maxNotesPerUpdate, evictStaleResults, with RPC/ACP protocol defaults. |
A protocol-owned session does not simply inherit the TUI's advisor defaults. Show effective state and persistence separately; never enable advisors as an attachment side effect. |
| Advisor definitions | Native configuration/editors exist. Neither the public RPC table nor the control-only command union contains advisor-definition CRUD. | Missing structured roster/configuration operations and change notifications. Do not edit native configuration files from NeoCode or equate subagent monitor APIs with advisor definitions. |
| Events and ownership | Control accepts the RPC union and forwards native session events. | NeoCode allows attached get_state/get_roles reads but protects owner mutations and drops idle attached events. Preserve the guard in the first slice. Later write parity needs accepted/rejected operations, reconnect reconciliation and updates visible in both clients. |
Sources at the NeoPi snapshot: RPC commands, roles, control settings handler, settings adapter, advisor settings. NeoCode: runtime ownership guards, existing role picker mapping.
First additive slice
Ship a read-only NeoPi session inspector in the web/desktop thread header. Read the bound, already-connected runtime through get_state and capability-gated get_roles. Show native session identity, terminal attachment versus NeoCode ownership, current model/effort/active role, configured fallback patterns and native resolutions. Include the observation time and Refresh. Explicitly label this a snapshot, not continuous synchronization.
Use neopiSessions.configuration, thread ID input, orchestration-read authorization, and the thread's recorded provider instance. Never choose the first enabled provider, launch a probe process, start a stopped session or substitute another native session. Report missing connection/capability accurately. Reject a session identity change during the read. Project only the requested fields, never raw state, prompts or credentials.
No NeoPi source changes. Open NeoPi PRs PsychedelicShayna/neopi#475 and PsychedelicShayna/neopi#477 concern advisor configuration, PsychedelicShayna/neopi#486 shared control/live ownership, and PsychedelicShayna/neopi#487 and PsychedelicShayna/neopi#488 also touch control/host.ts. Do not race those branches or depend on their unmerged behavior. Keep the implementation in NeoPi-owned modules and existing registration/header seams.
Web and desktop share this inspector. Mobile retains current conversation behavior; its inspector/editor is a later slice. Existing composer, Settings, picker and handoff remain unchanged. No generic RPC proxy, mutation editor or placeholder advisor screen.
First-slice acceptance:
- Correct native session/provider instance for both GUI-owned and terminal-attached runtimes.
- Changing a private terminal fixture's role and refreshing shows its new role/model/effort and native resolution; the native owner remains intact.
- Opening/refreshing performs only reads: no prompt, settings mutation, launch or resume.
- Missing capabilities, disconnection and identity changes produce accurate states, not stale success.
- Focused behavior tests, private GUI proof, signed PR to nightly, build/install/launch-check. No live DB/wallet run.
Remaining parity acceptance
- Role-definition edits preserve scope, fallback chains and effort semantics; both clients observe accepted changes and rejected writes.
- Advisor roster, enabled state, configuration, save and reset use authoritative NeoPi APIs, including protocol-default differences.
- Identity and single-writer ownership survive reconnect/concurrent clients; stale GUI state cannot mutate a replacement session.
- Changes through either client refresh the other without restart or duplicate configuration. Unsupported capabilities stay explicit; ordinary chat remains usable.
- Web, desktop, mobile and remote environments have explicit supported/unsupported paths through the same contract.
Missing shared APIs belong in coordinated NeoPi downstream issues, not GUI filesystem workarounds. Their precise contracts must account for the advisor/control work that actually lands. This first slice does not claim the editor or continuous-update criteria are complete. Other harnesses keep their existing behavior.
Owner's words (verbatim)
2026-10-20 NeoCode passages: verbatim contiguous excerpts from one dictated message
NeoCode and NeoPy are a separate thing, but also the same thing. They're connected, because NeoCode Should be made to be NeoPy centric, not just, oh, it's T3 code, but it supports Neo code. No, the whole, the whole fucking thing should be centered around NeoPy. With every other harness, you know, just being like, oh, and it supports Codex and Cloud Code and all these other harnesses, you know. Those are the secondary things. Those are the side features, right? But it will rely on NPI deck, and it will ask for, like, some way to get auth from NPI. NPI holds the auth database, it holds the auth broker, the auth gateway. These are things that are already implemented, right? Neo deck needs to connect to an instance of NPI that serves that, and Neo code also needs to connect to an instance of NPI that serves that, right?
Neo code is a new way of writing code. It's a new way of like locally producing software on your machine, right? Yes, you can connect to all the other harnesses, but the other harnesses don't have this idea, right? That's why Neo code needs to be modified substantially. I don't think RPC will be enough. It, maybe if we extend our RPC to that extent, where you can have that level of control, then yeah, sure. But you should be able to just, you know, connect to a remote instance of NPI with NeoPy, like a, a, you know, a daemon, a core, core daemon. And run stuff there, which is something that it can already do, by the way. it can connect to remote like machines and, you know, connect to the cloud. That's why I picked C3 code, because it already does this, but with its own, in its own way, right? But we can adapt it to our way. We can adapt it to NeoPy as the core, running in, you know, NeoCore daemon mode. And we can just simply connect it to that, and the interface, the graphical interface, it's clean. It's, it's focused exactly like around the philosophy of making it more abstract, right? It doesn't clutter the interface with bullshit. You just simply have threads on the left side that when they run, they're not highlighted. They go gray, and they automatically settle and go out of your way. Only the things that need your attention are actually, you know, visible or easy to see, right? It does this, you have to go in and turn on like the legacy see all threads related to a project thing to like go back to the way other harnesses do it, but T3 code is already revolutionary in the sense that it's doing something that no other harness is doing, right? And I'm aligned with its philosophy in that specific area.
Source: NeoCore vision file at its merged commit. Transcript spellings are preserved. The owner's words take precedence over this summary; the wider daemon/agent vision is not silently included in this slice.
Activity
Merge PR #114: feat(neopi): inspect connected session configuration (@…
PsychedelicShayna commentedon Oct 21, 2026
Note
GPT-6 Astra on behalf of PsychedelicShayna
The first read-only slice is merged and installed: #114, with the unnecessary #115 trigger change reverted by #117. Current installed source is
2d2de4b8a642575f191e4f53068ff21a6942077a; version0.0.42-nightly.20261021.39527488047; AppImage SHA2564cb3006a589786b1b6f9710f86016198740b6ee2ca54794a37c45e88ac67a7f4.Launch NeoCode from the existing desktop/Rofi entry, open a connected NeoPi thread, then use NeoPi session configuration in the thread header. It shows the authoritative native identity, ownership, model, effort, active role and fallback resolutions. Refresh reads again; this is not a live editor. A disconnected thread explicitly says it is not connected rather than starting a session.
Private
:10proof covered both ownership modes. GUI-owned native session01a15958-87ca-7000-a3ae-0552fba24dbfreported instanceneopi, Luna/low; final installed Refresh preserved its ID and advanced the observation time. Terminal-attached session01a15955-43a5-7000-8c3b-4d4636ad269areflected a native role change toeffort/xhigh after Refresh; owner PID936798remained alive and the message count stayed 8. The private fixture was restored to Luna/low with no active role.Final installed screenshot · Terminal role-refresh screenshot. The latter was captured on
dfcdfd43, before the trigger-only revert; backend code was unchanged. The final tree is identical to the original feature mergee0655c131a, and its matching compiled output was reused through supported--skip-buildpackaging.90 focused behavior tests passed; the corrected runtime file then passed 42/42. Contracts typecheck passed. Existing server/web fixture diagnostics are listed in #114. Normal desktop shell hydration, private copied data and
basic_textstorage were used—not the owner's live database or wallet. Savednpi-nightlywas used; this is not a fresh-default binary-selection proof. The old16849214artifact and desktop-entry backup remain for rollback.A Luna continuation succeeded on the source-identical original feature artifact. The final-artifact continuation hit external
turn_rate_limit_exceeded; no successful reply is claimed for that attempt. Its connected inspector and Refresh still passed. The earlier dismissal was repeating Escape input on the private display, not a trigger defect; #115's record is corrected. #116 tracks the independent published-nightly version-classification defect.Only the first-slice checkboxes are complete. Role/advisor editing, bidirectional configuration events and remaining cross-client parity are still open here. #48 separately retains
human: pendingfor any real-profile restoration run; its private proof is not being relabeled as live-profile proof.PsychedelicShayna commentedon Oct 21, 2026
Note
GPT-6 Astra on behalf of PsychedelicShayna
The next bounded slice is delivered: #122 plus its installed-proof repair #123, nightly
3c5789f31979d2325cf983cb12fa5596fd973eec.Installed:
0.0.42-nightly.20261021.39538342553.1. The NeoCode desktop entry now launches this artifact; a289 remains available for rollback. AppImage SHA256:f1f572e518071ba99218e326e9bb1b022313d8f2e00801b7783706b834883ff0.Use: open a connected NeoPi thread → NeoPi session configuration in the chat header → enable Follow model changes. Native model/effort events update the read-only snapshot. Closing the inspector or turning follow off cancels observation. It reopens in manual mode.
Installed proof: normal shell hydration, private state, hidden Xvfb
:10; no live owner database, wallet or display. Terminal-owned session01a15955-43a5-7000-8c3b-4d4636ad269a, provider instanceneopi, owner PID936798:MERCURY_FOLLOW_REPAIRED.effortappeared with effortxhighwithout Refresh; returning to Luna / low appeared automatically.waitingcheck.Before · After · Recording · Structured proof. The older release hosts evidence only; the tested version/source are above.
Focused verification: 103 server/contracts tests passed; final adapter changes passed 10/10. Contracts/client-runtime/web types passed; server retains the previously disclosed
serverSettings.test.ts:235diagnostic. Full JS/package rebuild and launcher syntax validation passed. No clean native rebuild or general review round.This does not complete #113: role-definition changes still need Refresh; advisor configuration, editing controls and mobile parity remain outside this slice. Cosmetic inspector spacing is tracked separately in #124. The real-profile authorization gap on #48 is unchanged.
PsychedelicShayna commentedon Oct 22, 2026
Note
GPT-6 Astra on behalf of PsychedelicShayna
The owner has now explicitly authorized native graphical model/provider/role configuration, shared persistence and two-way control, rather than stopping at the read-only inspector. The concrete /models page and provider authentication entry points are tracked in #137; live transcript/attachment state in #135; the native /switch picker in #138; per-model capability correctness in #129 with native PR PsychedelicShayna/neopi#495. This does not reopen already-proven inspector behavior or decide the generic #49 conversion mechanism. The owner also explicitly chose the NeoPi-only runtime cutover in #125.
Owner's words (verbatim)
2026-10-22 shared model/role configuration, contiguous excerpt
In the TUI, you can't simply click on the model. Well, you could, maybe that's a feature I might add, but I usually do alt M. That brings me to the the, the model page, right? Which is in reality not the model page, it's the settings page for, or what should be the settings page for providers, right? What alt M reaches, like slash models, should be what the provider's page in the settings is. Right? And doing alt M in T3 code does nothing. so doing it in Neo code should open that settings page with that provider list. But that settings page with that provider list shouldn't be hidden in the settings. It should be a button just like usage is. See how usage takes over the, like, composer page, but it doesn't get rid of the sidebar? And it just shows you like a back button. Same as like PRs, pull requests, even though the pull request section is, well, it's not broken, it's just that it's misreading my repository as belonging to, like, upstream and not me. But, fair. but you see how those two, they just take over the central, like, central page? Because they don't need a sidebar. Only settings needs a secondary, like a tab bar on the left. Oh, fuck, I hit appearance again. I hit appearance again. God damn it. Okay, let's wait 12 seconds for the program to unfreeze. Okay, there we go. but yeah. It's just, it needs a sidebar because there's a lot of things. Right. Just like the slash models section, that also has a sidebar. Perhaps there should be a button there, which you can click or you can hit alt M, and it brings you to this model selector, just like the, the view in the T Y. Except, and, except it, it replaces the sidebar, just like the settings button does, right? And the pull request button and the usage button doesn't, because neither of them require a sidebar, but the settings button does require a sidebar, but it just replaces it with setting categories, right? But the layout is identical. It's 100% identical. Where if you click that, that fourth button, right, it would act a bit like the settings button in that it would replace the sidebar that shows your threads, but it would, it would, it would replace it with all of the different providers, like obliteration, Alibaba Token Plan, Anthropix, Rebus, Cursor, Devon, GitHub Copilot, Google, et cetera, et cetera, et cetera. I went through it before. and then all of the ones that you don't have connected that are grayed out. That should, that what should be on the left. And at the very top, there should be like a divider section, and there should be like a, you know, all models. There should be effort rules, all models, and roles. So you should be able to, in that section, like basically copy the terminal user interface. Copy how that works. Just represent it graphically in a new page with a new button. And cause the terminal user interface already gives you the design. It's just, yeah, you just have a sidebar, and you have like a divider, then you have effort rules, another divider, and then you have all models and rules. Oh, sorry, roles. When you're in roles, that changes the page entirely. When you click on all models, that shows you every single model. And if you click on a model first, then you can assign a role later. If you click on a role, on a role first, then you select a model or a pattern or blah, blah, blah. There's, you know, complex behavior there with regular expressions and everything that we recently added, so you might want to, like, look into the code there. But you would basically want to mimic that, and you would be writing to the same settings file. Well, like a mutex or something, but I can do this from several, like sessions. I can do this from, from from several T3 code, sorry, from several NeoPy instances at the same time. Like, and they even update each other. Sometimes I change the theme in one and it updates the other ones. Or I change, like, a model of a role in one and it changes it in the other one. Why not share it also with the GUI? Why not share that same thing with NeoCode? I say yes, I say share it with NeoCode. Let NeoCode just be another surface.
Complete original message: #125. Native settings/auth semantics must remain authoritative; no GUI credential vault or filesystem settings writer is introduced.