THE DESK, END TO END

/explore is the live market discovery surface. each control on the tab row loads its own real list, and the source outputs are never mixed into one · a source that failed renders its own reason instead of a substitute list

a search box narrows the currently loaded list · typing a ticker, a name or a ca filters it, and a ca is detected and offered as a direct link to the token page. the filter row adds a sort picker and four minimums · market cap, liquidity, 24h volume and holders. a positive bound excludes a row whose value the source left missing, and the desk states how many rows were excluded for a missing bounded value. the max-age field is disabled on purpose: neither source reports a token's age, so the bound cannot be honoured

below the filter row the status line states the list's own freshness and a refresh control. the Call Out tab also prints its live threshold, read from the payload, never hardcoded

the ai badge is the decision model's own score over the market fields the row carries. it grades green at 70 and above, amber from 45 to 69, and red below 45. a small star on the badge marks a partial read: the list carries only part of the model's weight, and the tooltip states exactly how much. the token page reads the rest

the page is the header, the AI decision rail, a section tab strip, a 2x2 card grid and a full-width market card. market cap is shown once, in the header; no other panel repeats it, and no unit-per-token figure appears anywhere on the page

the decision rail is a gauge with the score out of 100, a filled verdict banner, a confidence bar, the positive and negative signals, the exact inputs that are missing, a verified · inferred · unknown split, and a factor breakdown that shows each component's weight and the points it earned

the main metric is the TOP 10 WALLETS / ACCOUNTS COMBINED SHARE · the labels are explicit and never the ambiguous Top 10%. where available the panel also shows the largest wallet share, the holder count, the individual top accounts, and the burn, LP, known and unidentified categories. when the source provided only the aggregate percentage the panel says so instead of inventing a breakdown, and it does not claim ultimate-owner resolution unless the implementation resolves token-account ownership. an unread read prints unread, never 0

X Radar lists up to five qualifying posts about the token, each already past the source's minimum-view and valid-link gates, with the author, the post age, the view count and an open link. NO QUALIFYING POSTS right now is a distinct state from X RADAR UNAVAILABLE right now

the two cards beside the holders panel name recognised buyers who provably bought · a hold is never reported as a buy and an unknown wallet is never labelled a KOL · and the tracked-holder ratio, which is the tracked holders over the total holders. being in the holders list does not make a wallet a KOL, and being tracked does not mean it bought this token. when the tracked read is capped the share is marked as a lower bound, and a partial read says so

projects, not chats. the sidebar creates, renames and deletes projects; opening a project expands its chats beneath it with a single new-chat action. deleting a project or a chat names exactly what it takes with it and asks first. projects and chats are stored server-side, and a chat with no project lands under the default one, so a thread is never orphaned

the conversation is one column with the composer fixed at the bottom. the composer accepts normal questions and a pasted token ca/mint. when a ca is supplied, mind identifies the token and the thread receives the token context · token identity, market data, intelligence, holders, security and X/news intelligence · and follow-ups continue on that established context: PASTE CA ONCE · BUILD GROUNDED CONTEXT · ASK FOLLOW-UP QUESTIONS · KEEP THE TOKEN CONTEXT. the ca does not have to be pasted into every message. switching the ca opens a new chat, so no read bleeds between tokens

the ground read behind a grounded answer surfaces analyze, holders, security, news, x-intel and tools · only the fields the backend actually returns

the collapsed token card carries a details disclosure with the full read: volume windows, 24h transaction counts, buys and sells, pair age, the top-10 share, the authority flags, the dex and the quote asset

not advice

the agents surface is a generic workspace for independent AI workers. an agent is not a token and not a due-diligence engine by default: it has its own name, role, description, instructions, tools, memory configuration, run mode, status and run history. the runtime is generic too · it contains no hardcoded token, due-diligence or score workflow. if an agent is set up to perform due diligence, that comes from the agent's own instructions and the task it is handed, never from the runtime

the workforce starts empty because the store ships no seeded agents. every value rendered for an agent is the value the API returned; a field the API did not return keeps its slot and reads "not set" rather than a guess. search filters this response by the agent's own name, description, role and tools text, and the category chips are read from the role text the owner wrote, not a stored category column

opening an agent reads the real entity and its real runs, and every edit PATCHes the entity, so an edit survives a reload. run modes MANUAL and ON_DEMAND run today; SCHEDULED and MONITOR are disabled and say "coming later" because the backend does not run them yet. status is printed verbatim from the entity · READY, RUNNING, PAUSED or ERROR

a task is run by POST /api/agents/[id]/runs with a flat body · inputType is text, ca or url, inputValue is the task itself and prompt is an optional extra line. the route stores the row and starts execution out of the request path, so the response is the honest queued row while the run advances in-process. a run left queued or running past the hard timeout by a dead process becomes failed with the real reason, so it is never queued forever

an agent can only use tools it has access to. the runtime executes real tools through the capability registry · a tool the model was not granted, or one that does not exist, is recorded as a refused step and never executed, and a tool whose source is not configured is reported with its real reason instead of being called. a fake tool trace is not acceptable, and a tool that fails records its real failure

memory is a JSON settings value stored on the entity · the create form writes { enabled, scope, notes }, where scope is shared across this agent or dropped when the run ends. it is stored and edited as JSON on the memory tab, and it is not described as vector, semantic, long-term or permanent memory, because those systems do not exist here

launch creates a token through the supported launch venue. the step rail reflects the form state on the fly; it is never a wizard and never gates the submit. you pick a venue, name the token, and sign the create with the wallet · nothing is signed or sent without that approval

the market pair is the quote/market asset selected for the launch. on the StonkFun / LaunchLab path the selector uses the live launchable pair set the venue returns · the list is read live and never a hardcoded source of truth · and the pricing for the selected quote (its raise, supply and decimals) is read from the venue. a third-party pair whose ticker or name carries a stray character is dropped from the picker rather than rewritten. the panel beside the form shows the live market pairs for reference

the accepted fields are the ones the form reads: token name up to 32, symbol up to 10 (stored uppercased), a description up to 200, a metadata uri, an image of png, jpg or webp up to 2 mb, an optional website and an optional x link (https or empty), and a required check that you know the token can go to zero. the summary describes the transaction actually built and nothing else

agent setup is the launch-specific AI due diligence engine, and it is different from the generic agents workspace. it evaluates the project/token currently being prepared. it runs the real persisted due-diligence run (POST /api/launch/analyze) and follows that run to a terminal status, and it works in one order: COLLECT EVIDENCE · VERIFY · ANALYZE · SCORE · FIND RISKS · VERDICT. every conclusion is tied to actual evidence preserving SOURCE, DATA, TIMESTAMP and STATUS, and a value no source reported stays unknown

the engine's sections are read at render time from its own config, so this list cannot drift: CONTRACT SAFETY, LIQUIDITY & PAIR, HOLDER STRUCTURE, MOMENTUM, SOCIAL and NARRATIVE. its bands map onto four published verdicts

the launch summary states only what is true for the transaction it signs: the launchpad, the supply, the program, whether the metadata uri is https or not set, the launch cost · network rent and fees, with no launch fee on the LaunchLab path · and the creator, which is this wallet. the create transaction is built from the venue's own sdk and signed by your wallet, and the metadata is pinned or self-hosted and served back when no pinning pair is set

nothing model, key or vendor related is sent to the browser. a missing key is an honest reason, never an empty 200 dressed up as a success. a malformed parameter is a 400 with the exact reason, and an unknown resource returns the actual not-found behaviour. empty successful data stays different from failed data. every read is read-only unless it stores a project, a chat, a run or an observation

a fresh read can also be warming on the first pass, before any scan has landed, and a list can be legitimately empty. both are stated as themselves and are never automatically interpreted as an error or confused with a failed read