/* ============================================================================
DIVONCI WORLD — AGENT DEVELOPMENT · BOARD GUIDE (screens_agent_dev_guide.jsx)
----------------------------------------------------------------------------
An in-page explainer. A "What am I looking at?" button in the board header
opens a modal that walks through every card on the Agent Development surface:
what it is, how to read it, and how to use it — plus a glossary of the trust
states and competence levels that drive everything.
Self-contained: manages its own open state. Shared globals: Icon, DEVD.
========================================================================== */
const { useState: useStateGd, useEffect: useEffectGd } = React;
/* ── small explainer building blocks ──────────────────────────────────────── */
function GBlock({ what, read, use }) {
return (
{what &&
{what}
}
{read &&
Read it{read}
}
{use &&
Use it{use}
}
);
}
function GCard({ icon, title, accent, children }) {
return (
{title}
{children}
);
}
function GStep({ n, title, children }) {
return (
Agent Development is the evidence-governed path an agent walks to earn the right to execute tools. It is deliberately separate from the Arsenal (the tool library) and the Command Console (identity & voice). Nothing here grants power — it tracks the proof that justifies it.
Access is not trust. An agent can be allowed to see or route a tool long before it is allowed to run it.
No promotion without evidence. Trust only moves up when a passed evaluation is filed against a gate.
The browser never writes. Every action drafts a payload and routes to an approved Worker endpoint — service-role keys stay server-side.
Use the menu on the left to jump to any card you can see on the board. Each entry tells you what it is, how to read the numbers, and what you can do with it.
The Track Template card turns a proven track into something reusable. Right now it holds supabase-expert-delegation — Viiera's Supabase delegation track — so you can hand the same evidence-governed structure to other agents.
How to clone it
Click Clone to other agents. A dialog opens showing exactly which template is being cloned.Tick one or more agents. Anyone who already has an active equivalent track is disabled — you must tick override to deliberately clone over them.Every clone is forced to restricted / training at the template's start level. No one is promoted — this is locked, on purpose.Hit Queue clone. You get a structured result preview (created / skipped) and the exact payload sent to the Worker action agent_development.clone_template. The browser writes nothing directly.
Cloning copies the gates, restrictions and required evidence — never the trust. Each new agent must earn promotion through its own evidence.
When a code (like a screenshot reference) can't be matched to a real mission or job, the system files an escalation instead of inventing one. The current example is code cd78afbc.
What you can do
If you later find the matching record, click Link to mission / job, paste its id, and queue the link action. The escalation resolves into a real reference.Only available to a sovereign-authority viewer. Without authority the button is locked — escalations can't be quietly cleared.
If a code can never be linked, it stays an escalation. The system will not fabricate a mission to make the warning disappear.
Some jobs touch protected runtime files and must run on a trusted, state-aware runner — never in a casual chat session. This panel shows who can safely run that work and what's currently blocked.
The failure of job bc561cbf (a 184s timeout) is exactly why this exists: protected work routes to an approved owner with state access, or it blocks — it does not silently fall back.