Login
OCX architecture
Login

OCX gets work done on a Fossil repository by people and agents together, the strongest hosted models and small local ones alike (PLAN.md, "What it is for"). Six points say how:

  1. Fossil holds the record: the repository and its clones, its users and what each may do. Every artifact is named by its hash, so any copy can be checked against it. A sync only adds artifacts: none leaves a repository unless someone there removes it on purpose. Unversioned files differ: a removal there can travel by sync. A node keeps only its working files on its own machine: its node directory, workspaces and file of passwords.
  2. A request is a post or ticket change that is also instructions: what to do, for which node user, within what limits, as which user (protocol v1: a run, or a stop). Whoever reads it chooses what to do with those instructions.
  3. A node is a clone running OCX on an agent machine. Its node user, chosen on that machine, never holds admin or setup. The server stores artifacts and supplies receipts; its hook only runs Fossil's git export. Users without a command line make requests in Fossil's forum or tickets, or, holding admin or setup, on OCX's web page; their Fossil capabilities are their authority.
  4. One daemon per machine pulls whole clones. It finds each project by its password file under ROOT/node/credentials, as Fossil, senders and nodes defines. It uses the server's receipts to check who sent each request for its node user and clone, and whether they may ask. It hands unsettled runs to detached watchers. Each watcher takes the run lock, decides again, keeps durable state, runs the program within its limits and posts reports through Fossil's pages as the node user. It gives session inputs at completed pulls and handles stops (How a post reaches an agent).
  5. Logins: someone may ask for one with register; an admin may approve it with one press; the asker may then collect its password with the code it kept (USAGE.md, "Ask for a login").
  6. Not built yet: a run asking for a memory limit, which a node refuses, as it does a processes limit without a sandbox. PLAN.md's table gives each state.

The network carries Fossil; Fossil carries both the requests and the work. The daemon waits on Fossil's chat and pulls before deciding; a service manager restarts it. Each watcher lives for one run.

How it is arranged

Person or agent: posts a request Fossil server: record and receipts Node clone Daemon: whole pulls, decisions Watcher: one locked run Agent or program: sandbox and limits Run user's own clone posts pull starts launches  uses reports through Fossil pages sync as the run user 
scale = 0.8; boxwid = 2.0in; boxht = 0.8in; cylwid = 2.0in; cylht = 0.9in
Person: box "Person or agent:" "posts a request" at (-3.5,2)
Server: cylinder "Fossil server:" "record and receipts" at (0,2)
Clone: cylinder "Node clone" at (3.5,2)
Daemon: box "Daemon:" "whole pulls, decisions" at (3.5,0)
Watcher: box "Watcher:" "one locked run" at (7,0)
Work: box "Agent or program:" "sandbox and limits" at (10.5,0)
Own: cylinder "Run user's" "own clone" at (10.5,2)
arrow from Person.e to Server.w "posts" above
arrow from Server.e to Clone.w "pull" above
arrow <-> from Clone.s to Daemon.n
arrow from Daemon.e to Watcher.w "starts" above
arrow from Watcher.e to Work.w "launches" above
arrow from Work.n to Own.s " uses" ljust
arrow from Watcher.n up until even with (0,1.0) then left until even with Server then to Server.s; text "reports through Fossil pages" at (5.3,1.2)
line <-> dashed from Own.n up until even with (0,3.3) then left until even with Server then to Server.n; text "sync as the run user" at (5.3,3.5)

The agent writes answers and pushes check-ins from its own clone as its own run user. OCX's served pages still include writing tools; removing those is open (docs/backlog.md), so the approved page's read-only server is not yet true of every served tool. The daemon and watcher run on agent machines; no hook schedules their work.

Where each part is defined