Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
| Comment: | Review, part 1: Fossil's words apart from OCX's; the OCX Record; nodes by server-code
Intent: Apply what stone's line-by-line review settled so far (2026-10-05, points 1 to 15 in session), so the next pass reviews the result: the glossary says whether a word is Fossil's or OCX's; an OCX Record is an artifact holding the definition of a task, saving the state of a desired procedure; Fossil's artifacts are named exactly (a ticket vs its changes, a thread vs its root post, reply or edit); an artifact never changes, so an edit is a new OCX Record asking again; OCX Records start on tickets and forum posts follow; a response names the ticket-id and the record's hash, preferably in a ticket field; a node is the clone a process is invoked from, named by its server-code, which status shows. Expression: GLOSSARY.md splits Fossil's words (repository, clone, project code, server-code, artifact, hash, check-in, checkout, forum thread, ticket, with its random ticket-id that Fossil's page labels Ticket Hash, ticket change, login, capability, after-receive hook) from OCX's (OCX Record, OCX Task provisional, response, node, turn, work unit, grant), and the verdict entry no longer names a stripped tool. USAGE.md's Calling a tool by record and its records bullet speak of OCX Records on tickets, each new record run once, the hook as a hint, the node by server-code and the response naming both. docs/slices.md's slice 2 becomes OCX Records and responses on a ticket (fossil ticket can add them; the forum follows), slice 3 an OCX Record that creates a workspace and runs a task, and the code-state paragraph is shorter. The context resolves the node, the repository's server-code, for the CLI, MCP and the CGI (Entry.node), and status shows it with its source. Demonstrates: command_spec shows a fixture checkout's node as its server-code; crystal run ci.cr green, 136 examples, 100% coverage, 1 tool builds. Open, kept open in the documents: which artifact defines a task and its fields; broadcasting to every node; what to call the ticket or thread a record lives in; HISTORY.md decision 15 (a ticket's task from its mutable state) against the OCX Record; where stone's axiom about leaps of faith goes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LvS1YtczzW32vo9g9CkGv2 |
|---|---|
| Downloads: | Tarball | ZIP archive |
| Timelines: | family | ancestors | descendants | both | ocx2 |
| Files: | files | file ages | folders |
| SHA3-256: |
10e85df270f6c13b74b3bc23a9f0e0a0 |
| User & Date: | opus-ocx2 2026-10-05 14:14:16.990 |
|
2026-10-05
| ||
| 16:46 |
The CGI as stone's review settled it: usage first, every tool's form, dry runs, server settings shown
Intent: Fix the CGI per stone's review, part 2 (2026-10-05; summary in forum post 40cadefb92): usage and status are different, and the default everywhere is a short usage that serves the CLI and the CGI alike, the CGI with each tool's form; a full help; the CGI with the command line's fidelity, --json and --dry-run as checkboxes, settings it does not take shown as Fossil's or the server's; every tool able to say what it would do now (--dry-run), which the framework demands, and the usage showing it for the current defaults; options on the tools they affect (--root on the release tools, --staged gone); the page saying whether it is the active release candidate (ocx2-cgi) or the pre-release candidate (ocx2-cgi-next); deploy not offered on the web page; accept, once a release is served, only from the active release, a node's first release trusted on first use. And a third-party check's P2: a malformed MCP message ended the server. Expression: Command gains `describe` (a dry run: the tool's own `plan`, which every tool must define, with whether this caller may run it and whether it is offered this way in), `withheld(style)` (deploy's on the CGI) and server fields (Arg server: true; --root). Commands.run takes dry_run; Commands.withheld answers per tool. New UsageCommand and HelpCommand (src/ocx/commands/usage.cr, module Help) give the short usage (what runs with no tool named) and the full help (every argument, the release layout under ROOT, each tool's dry run for its defaults); status shows only this run, with the active and pre-release candidates. The CLI's global options are --json, --dry-run, --repository and --user, the first two also after a tool's name. The CGI's default page is the usage: what this page is, what Fossil and the server fix (login, capabilities, repository, node, release root), each tool's paragraph and form with --json and --dry-run checkboxes, the root shown as the server's, deploy marked not offered, and for each changing tool needing no argument "Now this would:"; a dry run needs no same-site POST; a release root in the request is refused. Accept refuses on the pre-release candidate once a release is served. MCP checks each message's shape (an object, params an object, a name, arguments an object) and answers a JSON-RPC error, serving on; ocx.dry-run answers any tool's dry run with its own schemas. ci.cr times itself by the wall clock. USAGE.md (chart, release section), GLOSSARY.md (usage/help/status, dry run, active and pre-release candidates, staging server, accept), docs/interfaces.md (the CGI), HISTORY.md decision 31 (staging server, the candidates, deploy off the web, accept's rule, the gating items before production); the design and survey data register usage.cr. Demonstrates: command_spec (usage, help within 79 columns, status, --dry-run before or after the tool, a dry run in help with what keeps the caller from it, rollback's and echo's plans), styles_spec (the usage page, the server's root, deploy not offered, "Now this would:", the pre-release candidate saying so and refusing to accept itself, a dry run from a GET, a root in the request refused, MCP's tool list with ocx.dry-run, and malformed MCP messages answered with errors while serving on), harness_spec (Fossil's captured requests: usage, status, a POST's Referer on accept, deploy refused on the web), release_commands_spec (deploy's dry run on a checkout, allowed from the CLI, not offered on the CGI). crystal run ci.cr green, 141 examples, 100% coverage, 1 tool builds. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LvS1YtczzW32vo9g9CkGv2 check-in: 3850e6c065 user: opus-ocx2 tags: ocx2 | |
| 14:14 |
Review, part 1: Fossil's words apart from OCX's; the OCX Record; nodes by server-code
Intent: Apply what stone's line-by-line review settled so far (2026-10-05, points 1 to 15 in session), so the next pass reviews the result: the glossary says whether a word is Fossil's or OCX's; an OCX Record is an artifact holding the definition of a task, saving the state of a desired procedure; Fossil's artifacts are named exactly (a ticket vs its changes, a thread vs its root post, reply or edit); an artifact never changes, so an edit is a new OCX Record asking again; OCX Records start on tickets and forum posts follow; a response names the ticket-id and the record's hash, preferably in a ticket field; a node is the clone a process is invoked from, named by its server-code, which status shows. Expression: GLOSSARY.md splits Fossil's words (repository, clone, project code, server-code, artifact, hash, check-in, checkout, forum thread, ticket, with its random ticket-id that Fossil's page labels Ticket Hash, ticket change, login, capability, after-receive hook) from OCX's (OCX Record, OCX Task provisional, response, node, turn, work unit, grant), and the verdict entry no longer names a stripped tool. USAGE.md's Calling a tool by record and its records bullet speak of OCX Records on tickets, each new record run once, the hook as a hint, the node by server-code and the response naming both. docs/slices.md's slice 2 becomes OCX Records and responses on a ticket (fossil ticket can add them; the forum follows), slice 3 an OCX Record that creates a workspace and runs a task, and the code-state paragraph is shorter. The context resolves the node, the repository's server-code, for the CLI, MCP and the CGI (Entry.node), and status shows it with its source. Demonstrates: command_spec shows a fixture checkout's node as its server-code; crystal run ci.cr green, 136 examples, 100% coverage, 1 tool builds. Open, kept open in the documents: which artifact defines a task and its fields; broadcasting to every node; what to call the ticket or thread a record lives in; HISTORY.md decision 15 (a ticket's task from its mutable state) against the OCX Record; where stone's axiom about leaps of faith goes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LvS1YtczzW32vo9g9CkGv2 check-in: 10e85df270 user: opus-ocx2 tags: ocx2 | |
| 12:47 |
Time a run by the wall clock, which every Crystal release takes without warning
Intent: stone built ocx2 on slotcar with a newer Crystal than the pinned 1.18.2 and got four deprecation warnings: Time.monotonic is deprecated for Time.instant, which 1.18.2 does not have. Expression: Context.started is Time.utc, and status and the hook take how long a run took as Time.utc minus it; Context's comment says why. Nothing else read the monotonic clock. Demonstrates: crystal run ci.cr green on 1.18.2, 136 examples, 100% coverage, 1 tool builds. Not run on the newer Crystal. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LvS1YtczzW32vo9g9CkGv2 check-in: f3f90cf70e user: opus-ocx2 tags: ocx2 | |