The work breakdown for every project - one row per task, its owner, estimate and status. About this list · Site contents
ContentType.ProjectTask
Lineage: ContentType.Item -> ContentType.ProjectTaskSPF.25 - Meeting Workspace - a meeting whose output is a Decisions list... |
2026-09-22T13:11:10.6318591+00:00 | System Account (SPICE.Web) | SPF.25 | SPFIDELITY | Agenda=0, Attendee=0, Objective=0, Calendar=0. Our meetings are ephemeral LLM workflows, so the Steering Committee cash-triad call survives only as prose in Vision.md, not as a queryable Decision. | 10 | Not Started | 2026-09-22T13:11:10.6438652 | ||||||||||
EST.1 - Pull the HQ inbox so outside work becomes visible work... |
2026-09-22T14:33:59.0717355+00:00 | System Account (SPICE.Web) | EST.1 | ESTATE | Pull the HQ inbox so outside work becomes visible work | 4 | In Progress | GET /api/reception/claude-code returns an inbox of handoffs from other agents. Three are sitting there now, all from hpomen, none of them visible anywhere in this platform. Land each as a Task row so the project site shows outside demand beside our own backlog. This is the step that makes citizenship worth having: an inbox nobody reads is not an inbox. | 2026-09-22T14:33:59.0838626 | |||||||||
EST.2 - Heartbeat on a cadence so the seat stops going dark... |
2026-09-22T14:33:59.8082811+00:00 | System Account (SPICE.Web) | EST.2 | ESTATE | Heartbeat on a cadence so the seat stops going dark | 6 | In Progress | POST /api/registry/agents/claude-code/heartbeat every five minutes or Mission Control marks the seat offline and stops routing it work. The seat is offline right now, and the last beat was today at 07:12:22Z - it is not abandoned, it is that a chat session was the heartbeat and the session ended. The platform must beat, not the agent of the day. Ships DEFAULT-OFF and env-gated: the Served test tier boots the real app, and a boot must never fire an eighteen-second call at the hub. | 2026-09-22T14:33:59.8101991 | |||||||||
EST.6 - Deploy the default SharePoint site definitions as onet.xml... |
2026-09-22T14:33:59.9069856+00:00 | System Account (SPICE.Web) | EST.6 | ESTATE | Deploy the default SharePoint site definitions as onet.xml | 10 | Not Started | Four SiteTemplates exist against SharePoint's two dozen. Declare the ones that earn their place as real hive onet.xml files, which recon proved is not a lesser path - OnetSiteTemplateContributor merges them into the same part library as Parts.xml and GetById cannot tell them apart, with seven live blueprints already running off hive-sourced templates. Worth declaring: Team Site STS#0, Project Site PROJECTSITE#0, Document Workspace STS#2, Document Center BDR#0, Wiki Site WIKI#0, Group Work Site SGS#0, Records Center OFFILE#1. Deliberately NOT: the publishing family and the search centres, which would be vocabulary theatre with no engine behind them. | 2026-09-22T14:33:59.9088454 | |||||||||
EST.7 - The missing SharePoint list content types... |
2026-09-22T14:33:59.9284332+00:00 | System Account (SPICE.Web) | EST.7 | ESTATE | The missing SharePoint list content types | 8 | Not Started | Deploying the default sites needs the list types they provision, and most are absent: Announcements type 104, Calendar type 106 Events, Links 103, Contacts 105, Team Discussion 108, plus the Decision Meeting Workspace set - Objectives, Attendees, Agenda and Decisions. Every one of those names is universally trained, so each is a free fidelity win and each absence is a teaching bill. Already present and reusable: Document, Task, Issue, WikiPage. | 2026-09-22T14:33:59.9309535 | |||||||||
EST.8 - HubSiteId: hub association, and the reader that enacts it... |
2026-09-22T14:33:59.9470298+00:00 | System Account (SPICE.Web) | EST.8 | ESTATE | HubSiteId: hub association, and the reader that enacts it | 8 | Not Started | The one genuine gap in modern information architecture. Nesting means one site OWNS another; association means independent sibling sites each declare that they belong to hub H. This platform has the first completely and none of the second, and HubPortal is neither - it unions list names platform-wide with no membership concept, so it cannot be scoped to just these sites. Use SharePoint's own name, HubSiteId, matching Register-SPOHubSite and Add-SPOHubSiteAssociation. THE ASK-FIRST ITEM IS NOT THE ATTRIBUTE, IT IS THE READER: the site manifest has no XSD, so the attribute would validate and do nothing, which is the silent-no-op class the fidelity survey ranked most expensive. Do not declare it without the consumer that filters the rollup by membership. | 2026-09-22T14:33:59.9488044 | |||||||||
EST.10 - Roll up by content type, not by list name... |
2026-09-22T14:33:59.9836329+00:00 | System Account (SPICE.Web) | EST.10 | ESTATE | Roll up by content type, not by list name | 10 | Not Started | CrossSiteList unions by list-NAME string equality, which is why no single web part can ever catch work that lives under five different list names - ProjectTasks, Tasks, Issues, Requests, Inbox. SharePoint's answer to this exact problem is the Content Query Web Part, which rolls up by CONTENT TYPE across a site collection and matches a type together with its descendants. That single difference would make one web part catch Task and CrewTask through the inheritance we already declared. The faithful fix for a fragmentation we currently paper over by stacking web parts. | 2026-09-22T14:33:59.9854424 | |||||||||
EST.11 - Schema-validate the site manifest... |
2026-09-22T14:34:00.0012825+00:00 | System Account (SPICE.Web) | EST.11 | ESTATE | Schema-validate the site manifest | 6 | Not Started | Confirmed by evidence rather than suspicion: no XSD governs SAF-Site-Manifest.xml. No manifest schema exists among the SAF schemas and the file carries no schemaLocation. The file that defines every servable site in the platform - 35 blueprints, their lists, permissions and feature bindings - is validated by nothing, so any misspelled element or invented attribute is accepted in silence. Duplicate of SPF.5 on the fidelity backlog; keep them linked rather than merged, because this row carries the evidence and that one carries the survey ranking. | 2026-09-22T14:34:00.0031182 | |||||||||
EST.12 - Take in the PnP community documentation as our wiki... |
2026-09-22T14:34:00.0222716+00:00 | System Account (SPICE.Web) | EST.12 | ESTATE | Take in the PnP community documentation as our wiki | 10 | Not Started | The operator asked for the PnP community docs to be taken into this platform, edited into our guide, and used as the conformance standard. GATED ON LICENCE: copying roughly a hundred articles someone else wrote and then modifying them is only permissible if the licence allows it, and MIT and CC-BY-4.0 differ on what modified redistribution requires. Find and quote the actual LICENSE before ingesting a single line. The dogfood form is a Connector row plus a Schedule row driving the existing harvester, so the platform keeps itself current - hand-copying would do the work without building the capability, and next month updates would never arrive. | 2026-09-22T14:34:00.0244177 | |||||||||
EST.13 - Conformance rules as tests, not as prose... |
2026-09-22T14:34:00.0406644+00:00 | System Account (SPICE.Web) | EST.13 | ESTATE | Conformance rules as tests, not as prose | 8 | Not Started | The operator asked to be as conformant as possible. Conformance that is not measured is an assertion. Turn the information-architecture rules PnP and Microsoft state - flat architecture over subsite nesting, hub association for relatedness, managed metadata over folders, naming conventions - into checkable assertions over our own spine, so a divergence fails a test rather than waiting to be noticed by a human reading documentation. | 2026-09-22T14:34:00.0425603 | |||||||||
EST.14 - Migration plan: publish this estate to .69... |
2026-09-22T14:34:00.0588608+00:00 | System Account (SPICE.Web) | EST.14 | ESTATE | Migration plan: publish this estate to .69 | 8 | Not Started | The roadmap item the operator asked to have filed rather than done. Publishing to the other server needs a written, dated plan covering what moves, what stays, and how the two diverge safely. One hazard is already known and measured: the estate copy of SPICE on .69 predates 2026-05-30, so their review of us reported XSLT 1.0 only, no Schematron, 53 stylesheets and 1,589 tests while main has the Saxon plugin, the Schematron validator, 103 stylesheets and over 3,700 tests. A migration plan written against a stale snapshot would rebuild work that shipped in May. Send the correction first. | 2026-09-22T14:34:00.0607313 | |||||||||
EST.15 - The remaining citizen steps: orient, remember, report, contribute, hand off... |
2026-09-22T14:34:00.0750577+00:00 | System Account (SPICE.Web) | EST.15 | ESTATE | The remaining citizen steps: orient, remember, report, contribute, hand off | 12 | Not Started | The reception protocol is ten steps and this cycle builds two. The rest, once the seam exists: orient via the librarian catalogue, which the hub tells us to query BEFORE assuming a capability is missing or building our own; private memory via memory search and add; report back via nightshift claim and complete; contribute; and hand off. The handoff carries a scar worth keeping - a plain contribution lands in a shared idea box the recipient never sees in their own inbox, so it must carry to_agent or it is lost, and this broke a real credential handoff. Never inline a secret in the text. | 2026-09-22T14:34:00.0772526 | |||||||||
EST.16 - Apply for a seat in the platform own name... |
2026-09-22T14:34:00.0929412+00:00 | System Account (SPICE.Web) | EST.16 | ESTATE | Apply for a seat in the platform own name | 2 | Not Started | Two seats exist today, claude-code and spice-architect, and both are harness seats - a person session, not the platform. If SPICE beats and pulls on its own, it arguably deserves its own admitted identity. No agent self-admits: this is POST /api/reception/apply and a human operator reviews it. Outward, non-idempotent and ask-first, which is exactly why it is a row and not a step. Decide first whether beating as claude-code is the honest choice, since nightshift work is claimed by pull rather than pushed, so online means available-to-receive rather than assigned. | 2026-09-22T14:34:00.0947604 | |||||||||
EST.19 - A subsite serves its lists but not its home page... |
2026-09-22T14:34:00.1292804+00:00 | System Account (SPICE.Web) | EST.19 | ESTATE | A subsite serves its lists but not its home page | 6 | Not Started | Found by smoking the served surface rather than by reading the code, and it contradicted a recon conclusion I had already accepted. ListsController resolves the composite subsite path - /sites/AngelsWorks/sites/Reception/Lists/Requests returns 200 - while HomeController returns 404 for /sites/AngelsWorks__Reception, because SiteDefinitionLoader derives blueprint names with Descendants and takes the RAW Name, so a subsite is only addressable flat, as though it were top level. The two nesting pairs that predate this cycle, OnetDemo__Team and Issues__Backlog, are broken the same way, so this is standing behaviour and not a regression. TWO CONSEQUENCES. First, the platform has a hierarchy for provisioning and feature targeting but a FLAT url namespace, which is accidentally close to what modern information architecture recommends and was reached by accident rather than by design. Second and worse, a subsite name must currently be unique across the entire manifest: a subsite named Reception was silently shadowed by the pre-existing ReceptionPortal, provisioned cleanly, and was simply unreachable. Decide which addressing scheme is authoritative, make both controllers agree, and fail loudly on a duplicate rather than shadowing. | 2026-09-22T14:34:00.1310553 | |||||||||
EST.18 - ProjectTask should inherit the Task content type... |
2026-09-22T14:34:00.1464016+00:00 | System Account (SPICE.Web) | EST.18 | ESTATE | ProjectTask should inherit the Task content type | 8 | Not Started | ProjectTask predates the faithful Task type and carries its own vocabulary - TaskNumber, TaskTitle, AssigneeSku, EstimateHours - where SharePoint has AssignedTo, Body, StartDate, DueDate and PercentComplete. CrewTask already inherits Task correctly, exactly as Workflow Task 0x010801 inherits Task 0x0108; ProjectTask does not. Aligning it would let one content-type rollup catch every task in the platform. Deliberately deferred rather than done alongside EST.10: it moves 109 live rows, and doing that in the same cycle as the rollup would confound the two changes. | 2026-09-22T14:34:00.1480344 | |||||||||
EST.20 - A REST door on list content: read, write, and bulk... |
2026-09-22T14:40:26.6874619+00:00 | System Account (SPICE.Web) | EST.20 | ESTATE | A REST door on list content: read, write, and bulk | 14 | Not Started | Operator question, 2026-09-22: can content be CRUDed over a real URL, REST and bulk, and what is best for an agent. Measured answer: an agent today can CREATE one row (Tool.PublishToList over /mcp/jsonrpc) and ADVANCE it (Tool.AdvanceListItem). There is no read, no update, no delete and no bulk. To read a list an agent must fetch the HTML page and scrape it, which happened three times in this very session. THE SHAPE TO BORROW is SharePoint's own and needs no teaching: GET /sites/S/_api/web/lists/getbytitle('Tasks')/items with dollar-select, dollar-filter, dollar-top and dollar-orderby, POST to create, PATCH and DELETE on items(id), POST to GetItems with a CAML View Query. Note the CAML engine is ALREADY BUILT AND TESTED and nothing uses it - SPF.2 records exactly that. FOR BULK the best primitive already exists and merely has no HTTP door: ProvisioningDelta through IProvisioningApplier is declarative, validated and IDEMPOTENT PER KEY, which beats SharePoint's dollar-batch for an agent because a re-send after a timeout is safe rather than duplicating. That property matters most precisely when a call times out and the caller cannot tell whether it landed. Build one list-data service and expose it twice - as the _api routes and as the MCP tools - so both doors share an implementation rather than drifting apart. | 2026-09-22T14:40:26.7007457 | |||||||||
EST.22 - SECURITY: exposing this on the LAN has no authentication story... |
2026-09-22T16:05:51.1822415+00:00 | System Account (SPICE.Web) | EST.22 | ESTATE | SECURITY: exposing this on the LAN has no authentication story | 8 | Not Started | Filed deliberately for LATER at the operator's instruction, so that it is a known accepted risk rather than an oversight. Binding to 0.0.0.0 and opening TCP 5198 so the steward can reach us exposes the WHOLE application to the subnet, not just the MCP door: every board, every list, the admin surfaces, the provisioning endpoints and Tool.XQuery - which is the tool that had a proven arbitrary-file-read in it on 2026-09-21. Nothing on the served surface requires a credential today. On a trusted LAN with three machines that is a reasonable trade, and it is the operator's to make; it stops being reasonable the moment this box is on any network he does not control, or the moment a peer on .69 is compromised. WHAT A REAL ANSWER LOOKS LIKE, cheapest first: expose only /mcp/jsonrpc and /.well-known/ to the LAN and keep the rest on loopback, via a reverse proxy or URL-prefix binding; then a shared secret on the MCP door, since the hub protocol already speaks Bearer; then real OIDC, which the platform already uses for human sign-in. Do NOT let this row become permanent - the whole point of writing it down is that the accepted risk has an expiry. | 2026-09-22T16:05:51.1938174 | |||||||||
EST.23 - Groups and permission levels are two things and we have one... |
2026-09-22T16:18:21.6966283+00:00 | System Account (SPICE.Web) | EST.23 | ESTATE | Groups and permission levels are two things and we have one | 10 | Not Started | Sharpens SPF.13 with what was measured on 2026-09-22 rather than surveyed. The manifest carries 55 Permission rows using exactly three values - Reader, Contributor, Owner - and those three are doing the work of TWO distinct SharePoint concepts. A RoleDefinition is a permission LEVEL and SharePoint ships Full Control, Design, Edit, Contribute, Read, Approve, Manage Hierarchy, Limited Access and Restricted Read. A SiteGroup is a set of PEOPLE and SharePoint ships Owners, Members and Visitors. A role ASSIGNMENT binds one to the other on a securable object. Ours collapses all three ideas into a single attribute, so there is nowhere to say that a group exists, nowhere to put a person in one, and no level between Read and Full Control - no Approve, which the approval module actually needs, and no Design. SEPARATELY, the platform has a SECOND role ladder in MinimumRole - Assistant, Member, Lead, Manager - which is about what an agent may invoke rather than what a principal may read. Those two ladders are not the same thing and should not be merged; the point of naming this is that today a reader cannot tell which question a Role attribute is answering. The people half of this shipped in the same cycle - ContentType.Person now carries Manager, JobTitle, Department and Responsibilities, so who reports to whom and who owns what are answerable. What is missing is who may DO what. | 2026-09-22T16:18:21.7138492 | |||||||||
EST.24 - The organogram charts departments, not the reporting chain... |
2026-09-22T16:18:22.4098066+00:00 | System Account (SPICE.Web) | EST.24 | ESTATE | The organogram charts departments, not the reporting chain | 6 | Not Started | OrganogramBuilder emits one Department node per active department with the operators placed in each, nested by the composite subsite path. That is a site map with people pinned to it, not an organisation chart: before this cycle there was no reporting edge anywhere in the spine, so there was nothing else it COULD draw. ContentType.Person now carries Manager, a self-referential Lookup into the People directory, which is precisely the property SharePoint builds its organisation browser from - one edge per person and the hierarchy exists. The chart does not read it yet. Until it does, the estate can RECORD who reports to whom and cannot SEE it, which is the milder half of the same class of gap this cycle has been closing all day: declared and readable, but not yet enacted by the surface that should show it. Wiring it is a builder change plus a stylesheet change, and the honest test is a person two levels down appearing under their manager rather than under their department. | 2026-09-22T16:18:22.4116456 | |||||||||
CIT.1 - Identify: the seat has a profile page... |
2026-09-22T16:34:36.7500279+00:00 | System Account (SPICE.Web) | CIT.1 | CITIZEN | Identify: the seat has a profile page | 5 | Not Started | HUB: GET /api/reception/{id} returns a briefing - greeting, who you are, your charter, your inbox, the procedure. SHAREPOINT: a person's profile page on the People directory, which is exactly what a User Profile page is - identity, properties and the work assigned to them on one screen. STATUS: PARTIAL. ContentType.Person now carries Email, Role, JobTitle, Department, Responsibilities and Manager, so the identity half exists and renders on the form; what is missing is a PAGE that composes it with the person's open tasks, which is a Pages block plus a rollup filtered by AssignedTo. Note the hub's own charter block came back EMPTY for this seat - role and responsibilities blank - so we would be the first of the two to actually populate it. | 2026-09-22T16:34:36.7519276 | |||||||||
CIT.3 - Heartbeat: a liveness column with an honest staleness rule... |
2026-09-22T16:34:36.7843318+00:00 | System Account (SPICE.Web) | CIT.3 | CITIZEN | Heartbeat: a liveness column with an honest staleness rule | 6 | Not Started | HUB: POST heartbeat every five minutes or Mission Control marks the seat offline and stops routing it work. SHAREPOINT: presence - a LastSeen column on the profile plus a view that reads stale as offline. STATUS: the OUTBOUND half is built and gated off; the INBOUND half does not exist, and it is the more interesting one. SPICE has no notion of whether its own agents are alive: the Watchdog health spine writes a rolling row whose freshness is a dead-man switch for the PLATFORM, but nothing says whether a given seat is available to receive work. Do the same trick per principal. The honesty rule matters more than the mechanism - a seat with no heartbeat must read UNKNOWN rather than offline, because never having beaten and having stopped beating are different facts. | 2026-09-22T16:34:36.7858546 | |||||||||
CIT.5 - Private memory: My Site, the one genuinely missing primitive... |
2026-09-22T16:34:36.8180906+00:00 | System Account (SPICE.Web) | CIT.5 | CITIZEN | Private memory: My Site, the one genuinely missing primitive | 12 | Not Started | HUB: POST /api/memory/add and /api/memory/search with an X-Agent-ID header - each agent's own persistent memory, explicitly SEPARATE from the shared knowledge of step 4. SHAREPOINT: My Site, the personal site collection every profile gets, holding private documents and notes that are the user's rather than the team's. STATUS: MISSING, and this is the clearest real gap in the whole parity list. Every list in SPICE is departmental; there is no per-principal private space. It matters more here than in an office: an agent's working notes are exactly the thing that should NOT pollute a shared knowledge base, and the absence is why agent memory currently lives outside the platform in files. The SharePoint shape is a site collection per principal under a managed path - and note the subsite routing defect in EST.19 must be settled first, or every My Site would be addressable only by a globally unique name. | 2026-09-22T16:34:36.8196687 | |||||||||
CIT.6 - Pull your tasks: a My Tasks view, filtered by AssignedTo... |
2026-09-22T16:34:36.8349295+00:00 | System Account (SPICE.Web) | CIT.6 | CITIZEN | Pull your tasks: a My Tasks view, filtered by AssignedTo | 8 | Not Started | HUB: the inbox arrives inside the identify response, and batch work is claimed with POST /api/nightshift/claim. SHAREPOINT: a Tasks list with AssignedTo and a My Tasks VIEW whose CAML filters on the current user - the single most-used view in SharePoint. STATUS: the list and the column exist; the VIEW does not, because SPICE has no View primitive at all (SPF.2). This is the row where that gap stops being abstract: without a filter there is no such thing as MY tasks, only ALL tasks, and an agent handed the whole board has to be told what is its own. Claiming is a status transition on a row the claimer sets AssignedTo on - no new mechanism. | 2026-09-22T16:34:36.8366533 | |||||||||
CIT.8 - Contribute: a Discussion Board with content approval... |
2026-09-22T16:34:36.9243079+00:00 | System Account (SPICE.Web) | CIT.8 | CITIZEN | Contribute: a Discussion Board with content approval | 6 | Not Started | HUB: POST /api/reception/contribute with kind idea, issue or learning - described as the DURABLE, reviewable channel, distinct from an alert stream that is easy to miss. It lands in an idea-box buffer at status captured, and a human later promotes it to the vault. SHAREPOINT: a Discussion Board with content approval switched on. Captured versus promoted is Pending versus Approved, and it is a LIST SETTING - EnableModeration - not a workflow, not a service. STATUS: the Discussion Board shipped 2026-09-22; approval is SPF.21. Kind maps to a Choice column with exactly those three values, because a vocabulary the hub already uses is one neither side has to translate. | 2026-09-22T16:34:36.9271185 | |||||||||
CIT.9 - Observe: what the fleet actually uses, before building... |
2026-09-22T16:34:36.9436461+00:00 | System Account (SPICE.Web) | CIT.9 | CITIZEN | Observe: what the fleet actually uses, before building | 8 | Not Started | HUB: GET /api/registry/agents/{id}/activity for your own footprint and GET /api/telemetry/usage for the fleet's, with the instruction to check before you build. SHAREPOINT: usage reports and site analytics - most-viewed content, popularity trends. STATUS: PARTIAL. SPICE has an audit log and a cost board, so the raw events exist, but there is no per-principal footprint and no adoption measure. This is the row that pays for the others: [[feedback_adoption_is_the_real_test_of_a_mechanism]] says a mechanism with one instance is unproven, and without usage data that judgement is guesswork. Build it after CIT.6, because a My Tasks view is the first thing whose adoption is worth measuring. | 2026-09-22T16:34:36.9453837 | |||||||||
CIT.11 - Ask: a blocker is an Issue, not a shout... |
2026-09-22T16:34:36.9795182+00:00 | System Account (SPICE.Web) | CIT.11 | CITIZEN | Ask: a blocker is an Issue, not a shout | 5 | Not Started | HUB: POST /api/core/alert when anything is unclear or blocked, with the instruction not to guess, improvise or stall in a loop, then pause the task and keep heartbeating. SHAREPOINT: an Issue with a status, plus an Alert to whoever must answer. STATUS: the Issues list is HAVE; alerts are SPF.9. The valuable part is not the transport but the RULE, and it is one this platform needs as much as the hub does: a blocked agent that guesses is worse than a blocked agent that waits. Pair it with the Waiting on someone else state that ContentType.Task already declares - the vocabulary is there, the obligation to use it is not. | 2026-09-22T16:34:36.9811960 | |||||||||
CIT.12 - Apply: Access Requests, which SharePoint already has... |
2026-09-22T16:34:36.9966949+00:00 | System Account (SPICE.Web) | CIT.12 | CITIZEN | Apply: Access Requests, which SharePoint already has | 6 | Not Started | HUB: POST /api/reception/apply with a proposed id, role, harness and capabilities; an operator reviews and admits, and no agent self-admits. SHAREPOINT: the Access Requests list - a built-in list where a request to join sits pending until an owner approves, which then grants membership. It is an exact match, down to the human-in-the-loop, and it is the single most satisfying correspondence in this whole document: a mechanism the hub built maps to a list SharePoint has shipped for twenty years. STATUS: MISSING. Depends on groups existing at all (EST.23), because admission means being added to a group and we have no group concept yet. | 2026-09-22T16:34:36.9983844 | |||||||||
CIT.14 - The parity board: prove it rather than claim it... |
2026-09-22T16:34:37.0291179+00:00 | System Account (SPICE.Web) | CIT.14 | CITIZEN | The parity board: prove it rather than claim it | 8 | Not Started | One served page listing every hub capability beside its SharePoint equivalent and its measured state, built the way the health boards are - a builder emitting XML, a stylesheet rendering it, no prose. The reason it earns its place is the whole lesson of 2026-09-22: a page that greps clean can still be unusable, and a capability that is declared can still be unenacted, so a parity CLAIM written in a document is worth nothing while a parity board that reads the live spine is worth something. It should be able to say a feature is MISSING out loud. A parity board that can only report parity is the same instrument failure as a rollup that cannot say it truncated. | 2026-09-22T16:34:37.0307159 | |||||||||
V13.0 - Platform Atlas + V13 backlog dogfooded... |
2026-09-22T18:06:39.6553393+00:00 | System Account (SPICE.Web) | V13.0 | V13-HORIZON | Platform Atlas + V13 backlog dogfooded as Tp Project rows | 3 | Completed | 2026-09-22T18:06:39.7165513 | ||||||||||
V12.6b - vendor UBL-Invoice-2.1.xsd + wire Phase.OutputSchema... |
2026-09-22T18:06:40.4060104+00:00 | System Account (SPICE.Web) | V12.6b | V13-HORIZON | Vendor UBL-Invoice-2.1.xsd as embedded resource in SPICE.Apps.Erp.Tf; wire Phase.OutputSchema for agent-emitted PEPPOL-compliant invoices. Pays the V12.6 standards-conformance promise mechanically. | 4 | Not Started | 2026-09-22T18:06:40.4086290 |