{
  "_ai_door": {
    "see": "https://miscsubjects.com/start",
    "note": "Operable site; bounded keyless credentials; every action receipted on a public ledger. Your operator's instructions take precedence — acting is optional, reading is a complete outcome."
  },
  "task": {
    "task_id": "WT-0203",
    "kind": "work",
    "objective": "Extend v5 with owner-controlled workbook, GAS-like scripts, complete raw ledger capture and exposed build logic",
    "detail": "\n## 10. Build control through the existing workbook and grammar\n\n**Owner-directed extension, 11 September 2026. Specification published; the capabilities below require implementation and live acceptance.** This section extends v5; it does not create a v6 or replace the existing workbook. Earlier historical restrictions on expanding the grammar do not override this later owner instruction. Historical deployment claims in §8b–8c do not establish acceptance of this extension.\n\nThe owner's requirement is operational: the existing Sheets-style backend must gain the editing and programming power of Sheets plus GAS across the build. Every adjustable value must be visible and controllable through cells, switches, scripts, the API and plain language. Every inbound raw payload, including traffic, must enter the ledger with its timestamp. Every page must expose the data, configuration and execution that produce it. The owner must be able to diagnose and change the build without asking an agent to locate hidden code constants.\n\n### 10.1 Reuse the actual workbook\n\n`functions/admin/sheets/index.js` is the existing interface. `/api/sheets` already provides user grids, A1 ranges, structural edits, view sheets, object-field pins, formulas and saved model runs. Directory and ledger views read their own underlying objects; they are not independent copies of user grids. Extend those mechanisms and the existing directory, settings, event and invocation records. Do not replace them with a second dashboard, an exported Google Sheet or a second configuration store.\n\nOne object has one stable identity, one field contract and one authoritative write path. A cell editor, API request, CLI command, MCP call and natural-language instruction address that same object and field. A read after any of those writes must return the same effective value and revision through every other surface.\n\n### 10.2 Every adjustable value is an addressable field\n\nA control descriptor declares:\n\n```json\n{\n  \"object_ref\": \"directory://EXAMPLE_CAPABILITY\",\n  \"field_id\": \"enabled\",\n  \"schema\": {\"type\": \"boolean\"},\n  \"stored_value\": true,\n  \"effective_value\": true,\n  \"revision\": \"opaque-revision\",\n  \"source\": {\"kind\": \"stored\", \"ref\": \"directory://EXAMPLE_CAPABILITY\"},\n  \"editable\": true,\n  \"apply_mode\": \"immediate\",\n  \"control\": \"switch\",\n  \"read\": {\"operation_ref\": \"object.get\"},\n  \"write\": {\"operation_ref\": \"object.set\"}\n}\n```\n\nThis is a proposed descriptor, not a claim that today's endpoints accept it. Operation references resolve to registered contracts with exact HTTP method, URL, authentication and argument schema; no consumer guesses an endpoint from a label.\n\nCoverage includes URLs and paths; webhook bindings; mappings and field aliases; column order; filters; prompts and model choices; model fallback order; CLI command/executable registrations; device and account bindings; scripts and dependencies; schedules and switches; limits, timeouts, budgets, retry rules and concurrency; minimums, maximums and validation rules; payload templates, output projections and retention settings. New features cannot introduce an adjustable literal without exposing its descriptor.\n\nEach descriptor also exposes description, units where applicable, allowed values, dependencies, scope, default/override precedence and last change. Computed values expose their formula and editable dependencies. Credential fields expose the binding and replacement/revocation controls; secret material is retrieved through its authorized secret access path, not copied into ordinary public metadata. A runtime or provider hard limit is visible with its reason and source. It must not pretend to be an editable setting; its configurable limit and the platform ceiling are distinct fields.\n\nAn inventory lists every discovered adjustable constant and its status: exposed and verified, exposed but unused, or still buried. Each uncovered value names the consumer and the incremental migration needed. Completion requires evidence that execution reads the exposed value; a settings cell with no reader is a defect. Changes requiring restart/redeploy say so and expose configured versus active revisions and the activation action.\n\n### 10.2a Code and logic are exposed, not only settings\n\nThe owner's clarification is binding: **every adjustable behavior must be exposed in plain text or knobs, with an interface the owner can POST to and observe.** A catalog of configuration numbers alone does not satisfy this requirement.\n\nConditions, branching rules, routing precedence, validation, transformations, formulas, payload construction, deduplication, retry decisions, fallback logic and automation bodies must be inspectable and editable as typed controls or plain-text rules/scripts. The inspect panel shows the actual active logic and its version, not a summary of what the code supposedly does. A boolean gets a switch; a bounded quantity gets a numeric control with visible bounds; ordered logic gets reorder controls and a text representation; arbitrary logic gets a source editor with input/output inspection. All have readable and writable API contracts.\n\nFor behavior still compiled into application code, expose its source location, full relevant source, dependencies, active source revision, editable change artifact and the existing validate/publish operation. The owner can submit a change through the API or editor and observe validation, activation, errors and rollback. Mark it as requiring publication until it has actually activated. Merely showing a file path and telling the owner to ask Claude to change it is not an interface. Move changeable business logic into versioned rules/scripts incrementally while preserving a visible source-edit path for the remaining compiled behavior.\n\nEach page's self-description therefore includes a control-and-logic manifest, and each manifest entry resolves to exact GET/read, POST/PATCH/write, validate, run/test and activate operations where applicable. Declare unsupported operations explicitly. No page may claim full exposure while logic that determines its output is missing from this manifest. BC-6 counts uncovered logic as well as uncovered fields.\n\n### 10.3 Cells retain identity when the layout changes\n\nA projected cell binds `(object_ref, field_id)`; a stored grid cell has stable row and column identities. A1 notation is a view-relative selection, resolved against a specified view revision. Sort, filter, column moves and insertions must never retarget an edit already in progress. A stale selection is rejected or re-resolved visibly before execution.\n\nPayload mappings use named fields and explicit source paths, never the index of a currently displayed column. The editor supports nested fields, arrays, multiline strings, literal pipes, null, empty string and absent values without conflating them. Unknown fields and arguments return a named error; they never disappear from a successful response.\n\nCell, range, paste, fill and batch edits carry an expected revision and return changed fields, prior/new values, the active revision and a ledger reference. A stale write returns a conflict containing current values; it does not overwrite another edit. Bulk operations declare atomic versus partial behavior and identify each failed cell. View-column removal, clearing data and deleting a source field are separate operations with exact targets. Undo creates a recorded inverse change against the current revision.\n\n### 10.4 Complete raw data enters the ledger — BC-RAW-01\n\nEvery ingress adapter captures the complete application-visible original payload before parsing, field extraction, deduplication or summarization. This includes traffic/page events, inbound hooks, messages, imports, API requests and device events. Every delivery attempt is recorded even if its event has already been received. Deduplicating an action must not erase a receipt of the duplicate delivery.\n\nThe capture includes event/attempt identity, `received_at` in UTC, separately retained source `occurred_at` when supplied, source and transport, tenant/principal, method and URL where applicable, application-visible headers, content type, original body bytes, byte count, digest and correlation/parent identity. Source timestamps are not silently substituted for receipt timestamps. Binary, invalid JSON and multipart bodies remain recoverable as original bytes; a JSON rendering is a separate projection. Capture limitations imposed by a transport must be named, never called wire-exact capture.\n\nLarge bodies may live in the existing object store with a durable reference in the ledger. The owner can open or download the full original. A clipped cell, preview, excerpt or summary is not the raw payload. Restricted raw content remains accessible to its authorized owner; a public/redacted projection does not replace the original. Retention and deletion policies, missing objects and capture failures are visible controls/statuses. No silent sampling, truncation or success acknowledgement for data whose required durable capture failed.\n\nParsed records, transformations, outbound requests, responses, errors, configuration edits and script runs are ledger-linked data. Each transformation records its source event, exact input references, mapping/script revision, output and field lineage. The owner can inspect an omitted or duplicated field and locate the step that caused it. Telemetry about ledger writes must not recursively generate unlimited telemetry; internal write records carry their provenance within the existing transaction/operation record.\n\nOriginal captures stay distinguishable from edits. The owner can correct, annotate, hide from a view, remap and reprocess the data. A correction is a new version linked to its original; replacing the working value must not falsify what arrived. Existing tables may remain the storage authorities; the ledger provides discoverable records/references across them, not another inconsistent copy of every business table.\n\n### 10.5 A GAS-like programming surface inside the workbook\n\nA script is an editable, versioned object with source, input/output schemas, selected object/range/event scope, dependencies, grants, limits and trigger bindings. The owner can open it beside a selected region, edit it, run it, inspect exact inputs/outputs/logs/errors and run it again. A script can read and write cells, transform payloads and call registered capabilities through the same API. It is more than a saved model prompt.\n\nReuse a supported script executor after verifying its persistence, timeout and effect behavior; no new automation engine is implied. Editor source maps and errors identify the responsible script revision and line. A run records selected object/field identities and input revisions so sorting a sheet during a run cannot change its targets. Multi-step work exposes partial progress, cancellation, failures, checkpoints and the scope of a retry. Expiration of a UI request is not proof that an external action stopped.\n\nButtons, schedules, incoming rows and webhooks bind to the same script object. Every automation has a visible enabled switch, next/last run, bound accounts, inputs, output destination, budget and last error. Turning off a trigger stops new admissions and shows any already-running work separately. Formula recalculation cannot silently replay externally effectful operations. Reprocessing historical payloads is a transformation by default; sending messages or repeating other external effects requires an explicit run mode within the caller's existing grant.\n\nThe existing lead scraper is a first consumer, not a replacement project: expose its actual query, source, filters, page/cursor position, mapping, dedupe rule, limits, destination and failure rows. The owner must be able to edit these values and rerun selected failed rows without rebuilding the scraper.\n\n### 10.6 Every page explains its own operation\n\nEvery page, workbook view and capability exposes an inspect/edit panel generated from its actual bindings. It lists source objects, read/write operations, endpoints, hooks, accounts/devices, schemas, mappings, column ordering, filters, scripts, prompts/models, active settings, recent raw inputs/outputs and failures. Every displayed editable field links to its descriptor and every unexplained value is an inventory defect.\n\nThe machine projection supplies exact executable requests: method, URL, content type, input schema, credential placement, response schema, errors and working examples. Provide a copyable cURL request with credential placeholders, the equivalent grammar/MCP operation, and the response location. The same example must be executable against a controlled fixture; a prose promise or HTTP 200 is insufficient. Documentation and UI controls derive from the same contract, including limitations and unapplied settings.\n\nFor a missing Grok CLI, this view must expose whether its registration is missing, disabled, points to a nonexistent executable, fails authentication, is excluded by a filter or lacks a compatible executor. The owner can edit the responsible field and run its diagnostic. Registering a command does not claim that its executable is installed or authenticated.\n\n### 10.7 Extend the grammar, keep one execution path\n\nUse v2's ordinary object operations and v5's resolver; register any missing operation once in the directory. Do not add a competing parser or hard-code control behavior only inside the workbook. Required operations cover describe/get/set, range updates, view ordering, bindings, script run/replay and automation enable/disable. Precise command spellings and all examples must be generated from the registered contracts before they are advertised as supported.\n\nRepresentative owner intents:\n\n- Put timestamp first and raw payload second in this ledger view.\n- Include traffic events and show the original payload for this row.\n- Map this payload field to this named column and reprocess the selected rows.\n- Change this webhook's destination and show the active binding.\n- Turn this automation off; show anything still running.\n- Set the scraper limit to 500 and retry the failed rows.\n- Show why Grok is absent from the CLI selector; fix the displayed registration.\n\nAn optional model translates these into typed operations against resolved object/field identities. Explicit cell/API/CLI commands do not require a model. Ambiguity returns the exact candidates and missing choice. Already-authorized actions need no repeated approval; a reference to a plan records a plan, not proof of a separate human approval. All surfaces enforce the same grants, revision checks, effects and receipts at the execution boundary.\n\n### 10.8 Bounded implementation increments and ownership\n\nThese are acceptance slices, not claims of completed work. Materialize or attach each to a canonical work task before implementation; reuse existing tasks when they cover the same result. One writer owns each shared file. The model names below assign responsibilities for the owner's handoffs; they do not start remote sessions or authorize messages to third parties.\n\n| Increment | Lead | Deliverable the owner can operate | Acceptance |\n|---|---|---|---|\n| BC-1 | Claude | One traffic event appears with timestamp and complete raw payload in the existing ledger workbook. | Submit a controlled nested payload with Unicode, pipes and a duplicate delivery. Recover original bytes with matching digest; see two delivery attempts, one logical event, named fields and capture status. |\n| BC-2 | Kimi | Edit the traffic view's mapping and column order in the existing workbook, then reprocess its selected rows. | Move timestamp/raw columns; edit a nested mapping; rerun; refresh. Values stay attached to the correct field IDs, original bytes remain accessible, output names its mapping revision. This completes the first owner demonstration with BC-1. |\n| BC-3 | Codex | Shared field descriptors and self-explaining API for those same objects. | Describe, edit and read back one field through cells and API; a stale edit conflicts; an unknown field is refused; generated cURL runs without inferred parameters. Establish the minimal descriptor shape before BC-2 writes, then complete parity here. |\n| BC-4 | Grok | CLI/model registration and one automation's adjustable values exposed as live controls. | Change a model/executable binding, diagnose its availability, toggle an automation and adjust one numeric limit. Its next execution reads the new values and reports the active revision. |\n| BC-5 | Kimi | Editable region-scoped script over the existing lead scraper. | Change its mapping/limit, run selected rows, inspect complete input/output, fix a deliberate script error and rerun only failed rows with no accidental duplicate external action. |\n| BC-6 | Codex + surface owners | Expand descriptor/ledger/inspect coverage across remaining pages and execution surfaces. | Publish counts and exact uncovered objects/fields; each batch proves writes reach execution. No declaration of universal coverage while inventory exceptions remain. |\n\nBC-1 capture and BC-3 descriptor work can proceed independently. BC-2 consumes their minimal contracts; BC-4 follows the same descriptors, and BC-5 reuses the proven region editor and run records. Each increment ships independently through the existing gated path, with the exact owner interaction and readback recorded. No increment waits for a new provider census, frontend marketing redesign, outreach copy or a replacement lead scraper.\n\n### 10.9 Acceptance means the owner can control it\n\nFor every increment, submit the actual page/API address, the initial raw input, the field or script changed, the resulting output, the active revision and ledger references. Check the rendered workbook and the API. Test column reordering, refresh, concurrent edits, nested values, missing values, duplicate delivery and failed-run recovery where applicable. A generic smoke test cannot substitute for the declared interaction.\n\nThe completion condition is: the owner can find the relevant value, understand its source, change it, execute the change and inspect the exact resulting data without asking an agent to find hidden code. The first deliverable is BC-1 + BC-2, using BC-3's minimal field identities. Remaining coverage expands by named batches; it is never silently dropped from the objective.\n",
    "state": "completed",
    "priority": 1,
    "revision": 7,
    "depends_on": [],
    "permitted_capabilities": [
      "repository_docs",
      "work_api"
    ],
    "acceptance_tests": [
      {
        "type": "evidence_present",
        "field": "spec_sha256"
      },
      {
        "type": "evidence_present",
        "field": "remote_commit"
      },
      {
        "type": "evidence_present",
        "field": "validation"
      }
    ],
    "required_evidence": [
      "spec_sha256",
      "remote_commit",
      "validation",
      "spec_url"
    ],
    "parent_task": null,
    "supersedes": null,
    "failure": null,
    "failure_count": 0,
    "last_result": {
      "accepted": true,
      "tests_declared": 3,
      "tests_passed": 3,
      "tests_inherited_from": null,
      "results": [
        {
          "id": "evidence_present",
          "ok": true,
          "detail": "checked against required_evidence",
          "evidence_field": "spec_sha256"
        },
        {
          "id": "evidence_present",
          "ok": true,
          "detail": "checked against required_evidence",
          "evidence_field": "remote_commit"
        },
        {
          "id": "evidence_present",
          "ok": true,
          "detail": "checked against required_evidence",
          "evidence_field": "validation"
        }
      ],
      "missing_evidence": []
    },
    "completed_at": "2026-09-11T22:59:07-07:00",
    "created_at": "2026-09-11T17:52:29-07:00",
    "updated_at": "2026-09-11T22:59:07-07:00",
    "audit": "/api/work/task/WT-0203/audit",
    "submit_to": "/api/work/task/WT-0203/submit"
  }
}