@kolisachint/hoocode-agent 0.5.40 → 0.5.42

package/CHANGELOG.md

@@ -1,5 +1,154 @@
 # Changelog
 
+## [0.5.42] - 2026-08-31
+
+### Added
+
+- Two built-in review agents, `code-review` and `security-review`.
+
+  Both ride the existing `templates/agents/` channel, so they cost nothing to
+  wire: `embed-templates.mjs` already embeds that directory and `Task` already
+  dispatches by name. They are agents rather than skills because review is the
+  case isolation is for — a review reads far more code than its findings are
+  worth carrying, and in a subagent that reading never lands in the parent
+  context.
+
+  Their tool allowlists include `bash` for read-only git inspection but exclude
+  `edit` and `write`, so a review reports and the caller decides. A test pins
+  that.
+
+- `/new-canvas` scaffolds a styled page instead of a placeholder.
+
+  The template served `<p>0 note(s). TODO: build the UI.` — unstyled, and with
+  no pattern to copy, so every canvas started by inventing one. It now ships a
+  small correct page: palette as custom properties with a
+  `prefers-color-scheme` block, an explicit `body` background, a list, an empty
+  state, and a reduced-motion-respecting highlight on rows that changed.
+
+  It also demonstrates the thing `canvas-design` asks for. State renders on the
+  server, so the page is right the moment it loads and stays right with
+  scripting off; a `/state` endpoint and a one-second poll update it in place so
+  what the agent changed appears without a reload. Everything from state goes
+  through an escape helper and `textContent`, never `innerHTML`.
+
+  No CDN and no webfont: the page is served from `127.0.0.1` and now works with
+  the network off, which a remote script or font would have thrown away. The
+  markup is built with plain strings and concatenation rather than template
+  literals, because this file is itself generated and a backtick or
+  dollar-brace in it is an escaping hazard for no gain.
+
+- A built-in `canvas-design` skill, loaded only when a canvas is being built.
+
+  `/new-canvas` handed the model a protocol contract and nothing about design,
+  and the scaffold serves `<p>0 note(s). TODO: build the UI.` — so whatever a
+  canvas looked like was improvised from nothing. `artifact-design` does not
+  cover it and would mislead if it fired: a canvas is a live page served from a
+  loopback server, not a file written to disk.
+
+  What is different is the whole skill: the markup lives in a JS template
+  string, `node_modules` and `package.json` are forbidden so there is nothing to
+  install and no build, the protocol carries no theme so the page owns its
+  palette outright, state is mutated by both the agent and the person, actions
+  are tool schemas that cost tokens while an instance is open, and a reload
+  issues a new URL that kills the open tab.
+
+  Grounded in the catalog rather than invented: 22 of GitHub's 23 canvas
+  extensions import nothing but the SDK and `node:` builtins, and the flagship
+  `pr-artifact-explorer` is a read surface that sidesteps concurrent editing
+  entirely. The skill takes both as the house style.
+
+  It costs nothing per turn. `disable-model-invocation` keeps it out of
+  `<available_skills>`, materialization is unconditional so the file is always
+  on disk, and `canvasBuildBrief` names its absolute path at the one moment it
+  is worth reading. Measured: the surface is unchanged at 8,470.
+
+- A built-in `artifact-design` skill for building self-contained HTML visuals.
+
+  hoocode writes a visual as one `.html` file on disk that `/canvas` can open.
+  The skill covers what that file needs to be good: reading the treatment the
+  request actually calls for, writing the color/type/layout plan before the
+  markup, designing both themes through custom properties, and avoiding the
+  handful of looks generated design keeps landing on.
+
+  Named for the output rather than the activity: a bare `design` would sit in
+  the prompt next to `/new-canvas` and read as software design as readily as
+  visual design. Note that "artifact" is new vocabulary in hoocode; it names the
+  thing produced, not Claude's hosted artifacts.
+
+  Libraries get an explicit no by default. A hosted page and a file on disk fail
+  differently: a CDN dependency is free for a page that is always viewed online,
+  and fatal for a file opened offline, where Tailwind-from-a-CDN is an unstyled
+  document. Webfonts are the exception, because a fallback stack degrades
+  instead of collapsing.
+
+  Delivery is a `file://` markdown link, which hoocode's renderer turns into an
+  OSC 8 hyperlink wherever the terminal supports one.
+
+  It is the first ungated built-in skill, because there is no feature switch
+  that predicts a request for a visual. Measured cost is +130 tokens per turn,
+  of which part is the `<available_skills>` block header that no default session
+  previously paid; the two agents add +180 together.
+
+## [0.5.41] - 2026-08-31
+
+### Added
+
+- Sessions record the git branch they started on, and the resume list shows it.
+
+  A session you never named, that opened with "look at this", was unfindable in
+  the list — the first message said nothing and there was nothing else to go on.
+  The branch usually says exactly what the work was, and it is the rare piece of
+  meaning that can be written down safely: unlike a derived title it is a fact,
+  so it is still true a month later.
+
+  It has to be recorded rather than derived, because by the time anyone reads the
+  list the working tree has moved on. One optional field on the session header,
+  read from `.git/HEAD` at session creation — a walk up to the repo and one file
+  read, no subprocess outside the reftable case, sharing the footer's
+  implementation so the branch a session remembers is the string the footer was
+  showing at the time.
+
+  Shown in the picker only where it adds something: a session with a chosen name
+  already says what it is, and `main` names no particular work. Also in
+  `/session`. Sessions recorded before this simply have no branch and read as
+  they did.
+
+- A session chip: the session's name, filled with its colour, laid into the
+  top-right of the input box.
+
+  The name used to live at the tail of the footer's busiest line — after the
+  brand mark, the mode, the path and the git branch, in `dim`, the quietest
+  colour a theme has. It answered *which session is this*, and it was the least
+  visible thing on screen. The chip puts the same fact where the cursor already
+  is, and gives it a colour so it can be recognised rather than read.
+
+  Every session now carries a name and a colour without anyone setting one. Both
+  are pure functions of the session id: a two-word slug from a 32x32 vocabulary
+  (`amber-harbor`), and a slot in the six-colour identity palette the agent tags
+  already use. Because they derive from the id, a resumed session comes back
+  wearing the same chip and a fork gets its own, with nothing to store. `/name`
+  and the new `/color` override either, and those choices are written to the
+  session's `session_info` entry, which now resolves its two fields
+  independently — setting a colour cannot clear a name, and renaming keeps the
+  colour you have already learned. `/color` on its own opens a swatch picker
+  that repaints the live chip as you move through it.
+
+  The chip is laid into border cells the box was already drawing, so it costs no
+  screen row, and it yields where it should: to the `↑ N more` scroll indicator
+  on the same border, and to the box itself below 48 columns, where the footer
+  takes the name back rather than leaving it nowhere. The editor's border colour
+  is untouched — it still carries thinking level and bash mode, so identity and
+  agent state never fight for the same pixels.
+
+  The fill's ink is picked from its own luminance, which is what lets one code
+  path render on a dark theme's bright hues and a light theme's deep inks alike.
+  `theme.fill()` is the new primitive for that: the palette lives on the
+  foreground side, where `theme.bg()` could not reach it.
+
+  The session picker shows the same colour as a swatch per row, and the slug for
+  sessions nobody has named, so a session recognised by its chip is found the
+  same way in the list.
+
 ## [0.5.40] - 2026-08-30
 
 ### Added

package/dist/core/agent-session.d.ts

@@ -272,6 +272,10 @@ export declare class AgentSession {
     get sessionId(): string;
     /** Current session display name, if set */
     get sessionName(): string | undefined;
+    /** What to show for this session: the chosen name, else its auto-assigned slug */
+    get displayName(): string;
+    /** The session's colour slot (1-6), chosen or auto-assigned */
+    get sessionColorSlot(): number;
     /** Scoped models for cycling (from --models flag) */
     get scopedModels(): ReadonlyArray<{
         model: Model<any>;
@@ -519,6 +523,12 @@ export declare class AgentSession {
      * Set a display name for the current session.
      */
     setSessionName(name: string): void;
+    /**
+     * Set the colour slot (1-6) the session's chip is filled with. Written as its
+     * own field so it survives a later rename, and so setting it never disturbs
+     * the name.
+     */
+    setSessionColor(slot: number): void;
     /**
      * Navigate to a different node in the session tree.
      * Unlike fork() which creates a new session file, this stays in the same file.