# Implementation Status **Historical terminology note (2026-11-02).** The project owner corrected the identity terminology: there is no separate Principal concept; the platform identity is the **User**. In every entry in this document dated before 2026-11-02, "Principal" means User. The existing persisted Type is named Principal, but its records represent User accounts. Principal is a legacy implementation identifier, not a current architectural concept or a separate identity Type. Historical entries are retained unchanged as dated evidence; new entries use User. See [identity and governance](../architecture/identity-and-governance.md) and [legacy identifiers](architecture.md#legacy-principal-identifiers). ## User, commercial model and identity documentation reconciliation - 2026-11-02 **Status: DOCUMENTATION ONLY. No implementation evidence is claimed.** No application code, database, migration, Type, Operation, Genesis, configuration, workflow, STAGING or test change was made, and no test, build or deployment was run. - **Terminology.** User replaces Principal as the architectural concept; Person is a Business-scoped profile; neither requires the other. Existing Principal Types, columns, Operations, handlers, records and Genesis definitions are unchanged legacy identifiers. Reconciliation is future work blocked by the Stage 3D restriction (PRR-002; PRR-061). Frozen contracts carry a dated supersession note; historical records are unchanged. - **Commercial model.** Business subscriptions only; free User registration and Business creation; Licensed and Guest Users; working billing bands; derived conditions; unsubscribed preview requirement. This is **intended future architecture**. **Current state: all Businesses are treated as active; no subscription, entitlement, billing, activation or Guest enforcement is implemented** (a source search of `app/` found none). Nothing here restricts the current build or the Spearmint Design milestone (PRR-063, PRR-065, PRR-067). - **Open design.** Licensed/Guest derivation and edge cases, Guest authority scoping (PRR-064), pricing transitions, the preview-content mechanism (unresolved; synthetic content must never become genuine Business data), delegated-authority succession (proposed direction only; PRR-062) and the User-account to Person-profile mechanisms (PRR-066). - **Not verified:** no behaviour described as intended architecture has been built or tested. ## Production-readiness audit and standing rule - 2026-10-28 The platform is **not** declared production ready. The authoritative record of every temporary decision, deferred capability, known defect, architectural gap, operational dependency and production-readiness risk is the [readiness register](readiness-register.md) (50 items, PRR-001 to PRR-050; 3 Critical, 17 High, 21 Medium, 9 Low; none `verified resolved`). The register holds the 10-part gap assessment and the resolution sequence. This section is a summary; where it differs from the register, the register governs. **Standing rule.** No temporary decision, workaround, deferred capability or unresolved production-readiness risk may be treated as complete without explicit resolution evidence or a formally authorised acceptance decision. Every temporary or deferred item must have an authoritative record and a defined revisit trigger. Scope and date: audit of documentation, application source (targeted scans), tests, workflows, scripts, git history to commit `d2c0f09` and GitHub Actions run metadata on 2026-10-28, plus one read-only STAGING browser navigation. No test, build, deployment, migration or database command was run. Top risks (see register for evidence): - No production deployment, activation or rollback path exists (PRR-001). - Stage 3D remains PLAN ONLY / NO-GO FOR BUILD (PRR-002). - No complete Capability Definition is documented or implemented (PRR-003); the eight workspaces are Presentation-Object compositions (PRR-004). - Revisions silently default to 1 in runtime code (PRR-006). - The full test suite is not recorded green and CI runs no tests (PRR-029, PRR-030). - Deployment authentication and environment protections are weak or unverified (PRR-035, PRR-036); hosting prerequisites are not scripted (PRR-039). - Real Action effects and workflow runtime beyond Slice 1 are not built (PRR-016, PRR-017). Production blockers: PRR-001, PRR-002 and PRR-003 (Critical), and the High items listed in register Part B until each is resolved with evidence or formally accepted. No acceptance decision exists. Unverified areas: current STAGING database state, live recovery cases, accessibility and cross-browser behaviour, display-scope states, the semantic- retirement gate result, the full-suite result for `d2c0f09`, GitHub Environment settings and hosting configuration. Not inspected: production systems, STAGING database/server, GitHub settings, backup/monitoring arrangements, root completion-report contents, dependency vulnerabilities. See register Part C. ### Recorded temporary decision: View `target_type_revision` pin reverted Commit `2892813` pinned `target_type_revision` on capability Views; STAGING View Type revision 1 rejected it (`unknown_value_property@value.target_type_revision`) and the three IDY-008 reconciliation runs on 2026-10-28 failed. Commit `d2c0f09` reverted the pin and made the reconciliation workflow `workflow_dispatch` only. Edit now uses the record's own persisted `type_revision`; New is refused (409) and its action hidden for Views without an exact Type revision binding. The decision is tracked as PRR-008 and is resolved only by View revision 2 (PRR-009, blocked on Stage 3D). ## Identity models: contact profiles, Business details and governed grant extension - 2026-10-29 Scope: Person contact profile and Business details Types through the governed configuration installer, and the governed authority extension that covers them and the Constituent Type (PRR-052, PRR-056 to PRR-059). Decision record: [identity and governance](../architecture/identity-and-governance.md). **Verified on STAGING 2026-10-31** (Build #612 `0ecebc6`, profile migration #67; fix build `be6f7cd`, migration re-run): - Authority reconciliation run (workflow run 41209117369): baseline v10 for both shared grants (47 and 46 references), four dedicated grants created, both shared grants narrowed to v12 in one command; every per-target effective set is exact; `exact_scope_match`, `nothing_beyond_approved_scope` and `unrelated_targets_unchanged` true. A rerun returned `already_reconciled` (shared grants stay v12). A diagnostic after demo population showed the same verdict and v12, so population did not re-widen the grants. - Demo population created the three fictional contact profiles and their three relationships through the dedicated grants. - Person page (Alex Morgan) shows the Contact profile section; the profile record page shows email, telephone and biography; an edit of the telephone saved through the governed pipeline and persisted after reload (then restored). No horizontal overflow at 375 or 1536 on the Person, profile record, Business and Principal pages. Business shows its empty state ("No business details have been recorded yet"); Principal shows identity attributes only. - Defect found and fixed (`be6f7cd`): the Contact profile View declaration id `a2000000-0000-4000-8000-000000000011` coincides with an existing Policy Object, and `PresentationObjectProvisioningService::resolveConfigurationReference` left a literal match unresolved, so the collection could not load its View and rendered empty. The Business runtime Object now takes precedence; regression test `testProvisioningPrefersRuntimeObjectOverCollidingDeclarationId` fails without the fix. Full suite: 645 tests, only the five known `Idy006GraphTest` failures. - Not verified live: rejection of an unauthorised edit (covered by `BusinessTypeAuthorityExtensionTest` through the real command path, not exercised in the browser, which has only the administrator Principal). **Implemented earlier, now superseded by the verified list above:** - Manifest v6: Person Contact Profile and Business Details Types, Person to Contact Profile and Person to Principal Relationship Types, two Views. `Idy008InstallerTest` 22 tests pass. - `BusinessTypeAuthorityExtensionService::reconcile`, `bin/extend-business-type-authority.php` and `staging-business-type-authority-extension.yml` (PRR-060): one atomic command creates four dedicated identity grants and removes only the identity Type references from the two shared grants after a verified revision-history baseline (stops before mutation otherwise); idempotent; Spearmint-only. The read-only diagnostic reports the expected and effective operations per target, the baseline and `exact_scope_match`. Demo population no longer re-widens the shared grants. `BusinessTypeAuthorityExtensionTest` (13 tests, 335 assertions) and `SpearmintDemoPopulationTest` pass; full suite 644 tests with only the five known `Idy006GraphTest` failures (645 tests after `be6f7cd`). Pushed, deployed and run on STAGING (see the verified list above). The earlier additive extension was never applied (build `d5c145d` diagnostic showed it would leave excess operations). - Demo population: three fictional contact profiles related to the demo Persons. `SpearmintDemoPopulationTest` passes. **STAGING run order** (all workflows are dispatch-only; completed 2026-10-31): reconciliation workflow (installs the Types), authority workflow (mutating run, then a read-only run showing `exact_scope_match`), demo population, then the Presentation profile revision (rev 20) that references the new Types. **Blocked or open** (see register): date of birth and sex excluded (PRR-057); one-to-one cardinality unsupported by the slot store (PRR-058); Business to Person association and the Person to Principal link not instantiable (PRR-059); no UI creation of new-Type records (PRR-009); real Business Details values not seeded; Constituent fields not presented until the record-bound source filter exists (PRR-056 part b); Campaign and Milestone dates await Stage 3D (PRR-055, exit criterion: Stage 3D GO, Type revisions published through the governed route, then a history series meeting the PRR-051 criteria). ## KPI history coverage and compact metric-only cards - 2026-10-29 Scope: an audit of every capability KPI and a generic compact height for metric-only cards. Profile revision 18. The KPI inventory and the reason each KPI has or lacks a history series are recorded in PRR-051; the compact-height decision and the Campaign/Milestone date dependency (Stage 3D) are PRR-055; the rule is in [UI system](ui-system.md). Result: Finance Revenue, Expenses and Forecast and Marketing Responses remain the only charted KPIs (each charts the same filtered records as its headline by a declared date). No further KPI has a dated source that describes its headline value, so none was charted and no history was inferred from current lifecycle values. The 18 metric-only capability KPI surfaces were reduced from a preferred height of 12 to 6 (previously rendered at 192px with the content centred in empty space). Delivery evidence: commit `21ac5cb` (revision 18, tests: `tests\Unit` OK 174 with 1 skipped, `tests\Runtime\Presentation` OK 39, `git diff --check` clean). Build #602 (`21ac5cb`) and Build #603 (empty retrigger commit `e07ea02`) each failed within about 3 seconds with no steps and no retrievable logs (job log download returns 404), and Migration #56 (for the earlier docs-only `8c0b23e`) failed the same way after Build #601 succeeded. The run annotation (supplied by Stu) gives the cause: "The job was not started because recent account payments have failed or your spending limit needs to be increased." This is an account billing limit, not a defect in the repository, and the spending limit has since been raised. Build #605 (`0eeb422`, created 16:25:50Z, seconds after the limit change was reported) failed the same way and Migration #60 was skipped, so the change had probably not propagated yet. Build #606 (`7795a36`, docs only, 16:43Z) then succeeded, followed by Migration #61 (success, 16:45Z), so revision 18 is live. STAGING browser check (authenticated, 2026-10-29): every metric-only KPI card on Sales, People, Products, Projects, Knowledgebase, Operations and Marketing renders at 96px (was 192px; preferred height 6); charted cards (Finance, Marketing Responses) stay at 345px; no horizontal overflow at 375px on the Dashboard and the eight capability pages; Sales' next row starts 16px under the KPI row. The Dashboard KPI row is 269px because its Pipeline card carries a bar chart and the three cards share a grid row (the People and Projects cards there still contain only the literal "No trend history available" text; a content-aware rule for them is not yet done). ## Business and Principal detail templates (profile revision 19) - 2026-10-29 Scope: useful detail Views for the Business and Principal Types within the existing governance model. Authorities: [readiness register](readiness-register.md) PRR-052 and PRR-056; [identity and governance](../architecture/identity-and-governance.md). Verified causes. The persisted core views for Business and Principal are single-text-node roots that show only the name (and, for the Business, status); core reconciliation never rewrites persisted core objects, so changing the core profile would not reach STAGING. A `record_summary` template with a `parent_type_id` takes precedence in `presentationTemplateReferences`, which is how Person already works, so the correction lives in the governed main profile. STAGING id probe (read-only): the Business `contact_email` constituent exists but the authorised reader refuses it because the administrator's inspection grants name no Constituent Type target; the Business `address` and Principal `profile_note` constituents do not exist. That is the blocker recorded as PRR-056; it is an authority decision and no grant was created. The existing `bin/create-constituent-authorization-grants.php` (direct SQL, hardcoded ids) is not an approved route and was not run. Change: `business-record-template` and `principal-record-template` (and their name nodes) present every existing Type property (name, status, kind, created, updated) with a muted dash for an absent value and no fabricated fields. A test asserts the templates declare only Type-declared properties. A null object id no longer raises a `TypeError` that leaked a server path in the 404 message; it now returns "Object not found." Revision 19 (gates: profile JSON, runtime check, migration workflow default, test). Delivered: commit `f9e4a58`, Build #607 (run 40731340222, success 17:02Z) and Migration #62 (run 40731883304, success 17:03Z). Live STAGING check (authenticated, 2026-10-29): the Business page shows header, Active badge, Profile (Business name) and Record (created, last updated) sections with the Edit link bound to the Business View; the Principal page shows Principal name, Kind (Human) and the same Record section; the Business `contact_email` id and the non-existent `address` id both return a 404 "Object not found." with no server path in the response; People (20 rows, 96px KPI cards) and the Person detail page are unchanged. No data or layout was modified. Not delivered: constituent fields (PRR-056). The Principal header shows its Active badge, which resolves the earlier unverified question about Principal status. Tests: `tests\Unit` OK (175, 1 skipped), `tests\Runtime\Presentation` OK (39), `Idy006BPresentationTest` OK (50); five `Idy006GraphTest` failures are pre-existing (verified at `c9492a8`); the full suite was not run. ## KPI cards, trend correctness and Marketing composition - 2026-10-28 Scope: the three-row generic KPI card, a trend-correctness defect, Marketing Responses history, a Marketing composition fix and a read-only identity inspection. Profile revisions 16 (commit `7507bb1`, Build 599, migration 54) and 17 (commit `c1f46fa`, Build 600, migration 55), all success. Authorities: [readiness register](readiness-register.md) PRR-051, PRR-052, PRR-054; [UI system](ui-system.md); [identity and governance](../architecture/identity-and-governance.md). | Finding | Verified cause | Correction | |---------|----------------|------------| | Trend compared non-adjacent periods (Expenses "-36% vs previous month" compared October with August) | The projector emitted only buckets that contained records | Contiguous zero-filled axis with a per-point `complete` flag; trend uses the latest complete period against the one before it, states both and names excluded incomplete periods | | "May be incomplete" was a constant | Literal note text | Computed from the period end date against the server date (PRR-054) | | Granularity control offered grains with fewer than two periods | Renderer listed every declared granularity | Line charts offer only grains that draw a line; none left means the generic empty state | | KPI card layout | Icon spanned the metric rows; chart narrower than the card | Compact icon beside label, figure and caption; granularity row; full-width chart (shared CSS, no capability rules) | | Rows of chart KPI cards misaligned when one had no trend line | Cards were vertically centred | Cards that contain a chart align to the top (Finance metric offset 14px on all three) | | Marketing Responses KPI was a bare metric | No history had been authored although `received_at` is a declared date | `kpi_card` with week/month/quarter history (rev 16) | | Marketing row had two sparse 345px metric cards beside the new chart KPI | Equal row heights | Active campaigns and Published content are compact span-3 metrics; Responses, kind and channel charts share the next row (rev 17) | Not done, with reasons: Active campaigns, Published content and Milestone history (Campaign declares no date property, Milestone only `due_date`; Type revisions need Stage 3D, PRR-051); Dashboard People, Projects and Pipeline, Sales and Operations status KPIs (no suitable dated source). Project already declares `start_date` and `due_date`. No data was created or changed. Identity (read-only STAGING inspection, authenticated): the four identity Definitions exist and show only a name and Type reference; the constituent Type has no Presentation Definition and the Business, Principal and Person Views have no relationship section, so constituent presence is not observable by any authorised read path. The classification of blockers (technical, missing decision, missing mechanism, doable now) is in the identity document; the only unblocked item, core-profile revision 2 for constituents, awaits Stu's confirmation that it is the intended place for that data. No Principal, Membership, Authority or Person record was created and Stage 3D is unchanged. Verification: `tests\Unit` OK (173, 1 skipped); `tests\Runtime\Presentation` OK (39); `Idy006BPresentationTest` OK (50); `git diff --check` clean. The five `Idy006GraphTest` failures remain pre-existing (reproduced at `c9492a8`); the full suite was not run. STAGING (desktop 1536, mobile 375): Finance shows "+238% vs previous month (Sep 2026 vs Aug 2026. Oct 2026, Nov 2026 incomplete, not compared.)", Expenses "-100%" (September has no expense records, PRR-054), Month/Quarter on revenue and expenses and Month/Quarter/Year on Forecast; incomplete periods draw hollow dots and the tooltip reads "Oct 2026 (period not ended) Revenue booked: £72,000"; Marketing Responses shows Week/Month/Quarter and "0% vs previous month"; `style.css?v=dashboard-design-15` is served; Marketing, Finance and Dashboard have no horizontal overflow at 375 (`scrollWidth` 360). Layout preferences were not changed. Not verified: cross-browser and accessibility checks (PRR-027). ## UI refinement validation, KPI history and identity route - 2026-10-28 Scope: validation of commits `5211522` and `ea48d0e`, one test correction, a chart-labelling defect, Finance KPI history, and a document-only identity route. Profile revisions 14 (commit `8ca3e55`, Build 596, migration 51) and 15 (commit `aa730a5`). Authorities: [readiness register](readiness-register.md) PRR-029, PRR-051, PRR-052, PRR-053; [identity and governance](../architecture/identity-and-governance.md); [UI system](ui-system.md). Starting state (verified, not assumed): `5211522` and `ea48d0e` are on `origin/main`; Builds 594/595 and migrations 49/50 succeeded; the Dashboard geometry on STAGING equalled the authored profile (12 cards, `size-33`, heights 10/16/18 rem) after a reload, so the earlier layout test left no residue. | Finding | Verified cause | Correction | |---------|----------------|------------| | `testNestedPresentationObjectsUseIndependentContentLayout` still failing | Bisected: passes at `c9492a8`, fails from `1b1422f`, which changed `openSurface` from `(repeatedRecord && !outerSurface)` to `!outerSurface`. Nested non-outer elements no longer get a wrapper or a `presentation-mode-*` class; nothing in CSS or JS reads that class, and the nested grid keeps its own `data-content-columns`. The assertions were stale, not the renderer. | Test now asserts the real contract: 2-column outer grid in `presentation-mode-regular`, 3-column nested grid, no `presentation-mode-expanded`, one `presentation-object-element`, and no `data-presentation-preferred-height` unless declared | | Tooltip said "Responses by month: 11" while Quarter was selected | `label` (the tooltip measure) and `title` baked the time grain into three granular charts (Marketing, Operations, Finance) | Profile rev 14: label is the measure only ("Responses", "Executions", "Revenue"), title is "X over time" | | KPI cards showed no history | Finance KPIs were plain `metric` elements; the Dashboard KPIs have no dated source | Finance revenue and expenses KPIs are `kpi_card` containers (icon, metric, month/quarter line with `trend`) over the same filtered records; Forecast has a scheduled-by-month line with no trend claim (rev 15); generic "Not enough history to show a trend yet." state for lines with under two periods | KPI outcome: implemented where the data carries genuine dates (Finance `effective_date`). Not implemented, by design, for Dashboard People, Projects and Pipeline Value: demo records share one `created_at`, so a history would present seeding time as business history, and Sales `target_close_date` is a forecast. No history was fabricated and no data was changed. The route and dependencies are PRR-051. Cumulative totals over time and a comparison-period selector were not built (no aggregation extension is documented). Identity: document-only. The exact Type revisions, governed mechanisms and sequence are in the identity document and PRR-052. New finding: the Business and Principal Definitions already declare constituent Objects (`contact_email`, `address`, `profile_note`) that need no Type revision, but they are not presented and their presence on STAGING was not verified. Stage 3D remains NO-GO; no Principal, Membership, Authority or Person record was created or changed. Verification performed (STAGING, authenticated, desktop 1536 and mobile 375): - Charts on all nine pages: `cursor: help`, `tabindex=0`, tooltip category and value equal the mark data attributes, Escape hides the tooltip. Granularity Week/Month/Quarter switches marks, `aria-pressed` and the per-panel trend text on Marketing. - Calendar (Projects): multi-day events are translucent with a left accent, grid lines and date numbers visible, no overflow. - Sales collection table: title gap, filter tabs with counts, search, sortable headers and status pills render cleanly. - Finance KPI cards (rev 14): Revenue booked shows five monthly points and two quarters with "-50% vs previous month" and "+67% vs previous quarter" (latest period flagged as possibly incomplete); Expenses paid shows two months. Mobile (375): single column, no horizontal overflow (`scrollWidth` 360 within a 375 viewport), navigation off-canvas on load. - Rev 15 (Build 597, migration 52, both success): Forecast card shows the scheduled-by-month line with no trend text, in a row with Revenue and Expenses; mobile 375 has no horizontal overflow (`scrollWidth` 360 of 360). Marketing with Quarter selected now reads "Q3 2026 Responses: 11" (previously "Responses by month: 11"). Granularity selection is client-side only and was not persisted; no layout or data was changed on STAGING. - Composition scan of all nine pages (rows of `size-*` items): no short or unfilled rows other than the Projects "Project schedule" card, which renders at 66% width and 44 rem height. Its authored layout is full width and 22 rem, so this is a saved layout preference (PRR-053), not the profile. Who saved it was not established and it was deliberately not changed. Tests run (current checkout): `tests\Unit` OK (172, 1 skipped); `tests\Runtime\Presentation` OK (37); `Idy006BPresentationTest` OK (50); `TargetReleaseManifestTest` OK; `git diff --check` clean. The five `Idy006GraphTest` failures reproduce identically at `c9492a8`, so they predate this phase (verified, cause not investigated, PRR-029). The full suite was not run. Limitations: Dashboard KPIs for People, Projects and Pipeline Value have no history (PRR-051); Forecast and the trend text compare only the last two periods; Expenses has two months of data; the Projects "Project schedule" card shows a saved preference (66% x 44 rem) that leaves unused space beside it and can be reset from the layout editor by its owner; saved layout preferences override authored sizing (PRR-053); the platform is not production ready (PRR-001 to PRR-053). ## Shared UI refinement, interaction polish and card sizing - 2026-10-28 Scope: generic renderer, CSS and JS only. Profile revision 13 (commit `3d6f116`, removal of the data-defined `dashboard-date-range` "Last 30 days" node) and the mobile topbar single-row layout (`77790f8`) are earlier parts of this series. Shared refinements are commit `5211522` (Build 594, migration 49). | Item | Root cause | Correction | |------|------------|------------| | Calendar spanning events | Solid, saturated tone backgrounds plus a brightness filter hid grid lines and dominated the week | Translucent per-tone fill, 1px translucent border, 3px solid left accent, dashed ends for clipped starts/ends | | Collection title/filter/table spacing | Title margin, region gap and header padding were ad hoc | `--list-title-gap`, `--list-block-gap`, `--list-head-pad` tokens | | Filter/sort/granularity/calendar-nav contrast | Global `button:hover` teal background and `--shadow-control` leaked into compact controls, giving a solid hover with unchanged dark text and a pink halo | One shared compact-control block: accent-soft hover with accent-strong text; solid accent with white text when selected; no shadow; visible focus | | Search focus | Global `input:focus-visible` outline out-ranked the wrapper rule, giving a nested green ring | Wrapper `:focus-within` border and ring; inner input has no outline or shadow; disabled and invalid states at the wrapper | | Pointer/popup | Crosshair and pointer cursors, no keyboard access to marks or legend | `cursor: help`, focusable marks and legend items, shared tooltip on hover or focus, Escape to dismiss, legend/mark highlight | | Card minimum size | 192px floor enforced in four layers: inline style, `.presentation-item` CSS, resize JS, and `max(12,…)` / `< 12` in `PresentationPreferenceService` | Floor lowered to a 1rem positive integer in all layers; `preferred_height` is emitted and persisted only when a PO or preference declares it; the `UserPresentationPreferenceTypeRevision` schema already had no minimum, so no Type revision was needed | Minimum-size decision: height is a floor that content always overrides, so nothing is clipped. Width remains the documented 2/3/4/6-of-6 span enum, so the narrowest card is one third; changing that would be an undocumented grid contract change and is not made here. Authored profile heights of 8 and 10 rem (previously raised to 12) are now honoured. Verification performed (STAGING, authenticated, 2026-10-28): - Build 594 succeeded; migration 49 succeeded; CSS `dashboard-design-13` is live. - Calendar (Projects): spanning events readable, translucent, grid lines visible, no overflow. - Sales list: tab hover computed `rgb(242,231,245)` / `rgb(113,54,129)` with no shadow; selected tab `rgb(113,54,129)` / white; sort header hover accent-soft with no shadow. - Search focus (list and topbar): input outline `none`, input shadow `none`, single wrapper ring. - Donut chart: legend hover shows the tooltip and highlights the slice (`cursor: help`); keyboard focus on a slice shows the tooltip; Escape hides it. - Layout editor on the Dashboard: resized a card to 3rem (below the old floor), saved, reloaded and the value persisted; the card was never clipped (content height 451px); restored to the authored 16 and saved again. - All nine pages at 375px and 1536px: no horizontal overflow and no clipped presentation items (18 checks). Tests run: `tests\Unit` OK (172 tests, 1 skipped); `Idy006BPresentationTest` OK (50); `TargetReleaseManifestTest` OK; `tests\Runtime\Presentation` 37 tests with one failure, the pre-existing `testNestedPresentationObjectsUseIndependentContentLayout`. KPI trends (not changed): the Dashboard KPI cards for People and Projects keep the explicit "No trend history available" state, and Pipeline Value remains a per-opportunity bar chart (no time axis, so not presented as history). No trend or comparison is fabricated. The demo records were all created on one day and `target_close_date` is forward-looking, so a created-at history would be degenerate and a close-date grouping would be a forecast, not a trend. Revisit when demo data has genuine historical spread or a Type revision supplies a dated field; the chart contract already supports `group_bucket`, `granularities` and `trend`. Person, Principal and Business presentation (document-only): Principal and Business views come from the governed `core-object-presentation-profile.json` (revision 1, `display_name` and `status`). The fields requested (Person date of birth, sex, contact details, biography, qualifications; Business addresses, registration identifiers, contacts, website) do not exist on the Types and each needs a governed Type revision, which Stage 3D (`platform.type_revision`, NO-GO, PRR-002) blocks. Date of birth and sex additionally need purpose, access and data-minimisation decisions, and any demo values must be clearly synthetic. No Principal, Membership or Authority records were created. The proposed concept map and its five open owner questions remain in `docs/architecture/identity-and-governance.md` awaiting Stu's approval. Revisit conditions: Stage 3D authorised for build, identity-model questions answered. Limitations: Edit still resolves through the record's own Type revision; New remains hidden for Types that need a revision; width below one third is not available. ## Eight-capability demo business and presentation restoration - 2026-10-27 Scope: demo data, Presentation Objects and the generic renderer for People, Products & Services, Sales, Marketing, Operations, Projects, Finance & Accounts and Knowledgebase. No Type revision, vocabulary digest, deployment mechanism or production configuration changed. ### Audit findings | Class | Finding | Evidence | |---|---|---| | Data | 1-4 records per Type in five capabilities; no dates spread across months | demo service counts (53 records) | | PO composition | People, Sales, Marketing, Operations and Knowledgebase roots never restructured; 192px sparse cards | profile revision 10 | | Generic vocabulary | no grouped aggregation, SVG charts, collection table, detail layout, summary row, `percent`/`datetime`/`avatar` formats | renderer and projector | | Projection | chart produced one point per record only | `projectDisplay` | | Styling | collection and detail pages were raw spans and unstyled links | `/objects?type_id=...` | | Drift | none found between source and STAGING | live audit | ### Implemented - Demo data (`SpearmintDemoPopulationService`): 212 records and 83 relationships, idempotent by stable identity. Reference date 2026-10-27; statuses agree with dates. Every project has 2-4 milestones and 2-4 people. Corrected existing values: two Harbour milestones completed to planned, `financial-project-revenue` received to invoiced, `financial-software-expense` dated 2026-10-05, and two contractor/training payments paid to approved because their dates follow the reference date. - Profile revision `11` (209 nodes): headers, KPIs, grouped SVG charts, tabbed tables and actions for all eight capability pages; dashboard cards navigate to their pages; four new relationship collections; every record template declares `display.collection`, `display.summary` and `display.detail`. - Projector: grouped chart aggregation (`group_field`, `count`/`sum`, `month` bucket), `projectCollectionTable`, `display.data.record`. - `TargetHtmlBoundary::objectList` renders one table when the template declares `display.collection`. - Renderer and CSS (`dashboard-design-7`): SVG bar, hbar, line and donut charts; `datetime`, `percent`, `number` and `avatar` formats; default status tones; compact summary rows; role-aware detail layout; pagination link. - Migration transport: the profile is now gzip-compressed before base64 (the revision 11 profile exceeds 128 KiB when only base64-encoded). Workflow default expected revision is `11`. - Tests: profile structure for all eight pages, chart and table invariants for every node, SVG chart rendering, compact summary and detail rendering. Full suite 605 tests; the only failures are the pre-existing `testNestedPresentationObjectsUseIndependentContentLayout` and five `Idy006GraphTest` cases. `bin\target-check.php` passes. ### Defects found during STAGING verification - Marketing failed with "Object of class JsonObject could not be converted to string": object-reference field values arrive as `JsonObject`, and `formatListValue` cast them to string. The renderer now formats only scalar values (commit `272bac9`). - Bar/line charts scaled their SVG text with card width; non-donut SVG width is capped by CSS (`max-width: 28rem`). - The People list rendered per-record cards. A legacy `record-detail-person` Presentation Object (`binding_mode: object_type`, no `display`) predated the revision 11 `person-record-template`, and `presentationTemplateReferences` returned whichever matched first in storage order. A template that declares `display.kind = record_summary` now takes precedence; other matches remain the fallback (commit `8c6abec`). No capability-specific branch was added. ### STAGING acceptance evidence | Item | Evidence | |---|---| | Commits | `72ea2c2` (demo data, profile revision 11, renderer), `8dda93c` (remove one-time trigger), `272bac9` (scalar guard, chart cap), `8c6abec` (template precedence) | | Demo population | run `40556880620` success (212 records, 83 relationships) | | Build | run `40556880839` success | | Profile migration | runs `40557284572` and `40558596927` success; final run for `8c6abec` success; profile revision 11 live | | Workspaces, 1536px and 375px | Dashboard, People, Products & Services, Sales, Marketing, Operations, Projects, Finance & Accounts and Knowledgebase load with no error text and no horizontal overflow | | Charts and tables | Dashboard 3 SVG; Products 2 charts, 1 table; People 2 tables; Sales 2 charts, 2 tables; Marketing 4 charts, 5 tables; Operations 2 charts, 5 tables; Projects 2 charts, 2 tables; Finance 2 charts, 1 table (22 rows); Knowledgebase 2 charts, 2 tables | | Collection pages | People (13 rows), Organisations (7), Offerings (13), Prospects (9), Work (8), Milestones (20), Knowledge items (10), Projects, Finance and Campaigns render as tables with no per-record cards | | Detail pages | Project (sections plus related Milestones and People) and Person (profile plus related Projects and Organisations) render with edit/back/relationship actions | | Layout editing | On the Dashboard, a drag reorder and a resize were saved, survived a reload, then were reverted, saved and reloaded to the original order and sizes | | Projects KPI = 10 | The demo business has 8 projects; two pre-existing STAGING acceptance projects ("STAGING Logic Acceptance Planned Project", "STAGING Acceptance Project 2026-10-13") were not edited. People = 13 includes "STAGING Acceptance Person Edited 2026-10-13" | Visual assessment: the Dashboard and workspaces use the reference shell, KPI cards, SVG charts, status pills, avatar stacks and tabbed tables. Browser screenshots from the automation tool are clipped on the right edge, so layout conclusions rely on DOM measurements as well as the visible portion. ### Known limitations - Chart x-axis labels on narrow bar charts crowd together; label thinning is not implemented. - Only ten Types have View Definitions, so Opportunity, Goal, Audience, Content, Response, Execution, Exception, Handover, Resource and Assertion have no row links, collection pages or detail pages. A governed view reconciliation is the follow-up. - Person and Organisation Types have only `display_name`. - Tab and search filtering is client-side. - The default status tone palette lives in the renderer as a convention. - Agenda mode, `date_span` progress and per-record relationship counts are not implemented. Superseded Presentation Objects remain as orphans. ## Capability workspace composition restoration - 2026-10-27 Scope: Presentation definitions, demo data and the generic renderer, measured against the approved Pastel SaaS dashboard and capability-page references. Deployment and governed reconciliation were not changed. ### Verified causes - **Composition (definitions and projection):** `TargetHtmlBoundary` treated root children as independent selections, so the Dashboard `page_header` was dropped, and capability roots held no header, KPI, tab or table Objects. The projector did not carry `source.filters` or sort fields. - **Demo data:** records were few and constrained by revision-1 Type descriptors (`additionalProperties: false`), so collections were sparse. - **Renderer:** `record_list` rendered unlabelled spans (no table, formats, badges, toolbar or links); `page_header` was not composable; `metric` had no icon or caption. ### Implemented - Profile revision `10` (142 nodes) in `database/configuration/idy-008/generic-business-presentation-profile.json`: page headers, KPI metrics with source filters, and tabbed searchable `record_list` tables for the capability roots. The superseded `*-page-body` Objects remain as orphans because there is no delete operation. - Projector: `source.filters`, `sort_field`, `sort_direction`. - `TargetHtmlBoundary`: embeddable root children render. - Renderer: `page_header` partitioning, `metric` icon/caption, `record_list` table mode (formats, badges, `row_links`, `max_rows`, tabs, search toolbar). - Shared CSS (`dashboard-design-6`) and new `presentation-lists.js`; the layout editor manages only items carrying `data-presentation-object-id`, so the page header is not draggable or saved. - Demo data: 11 further records (53 creates, 20 relationships) through `SpearmintDemoPopulationService`. - Docs: `views-and-content.md` and `ui-system.md`. - Release packaging: `release/target-release.json` now lists `presentation-lists.js` (the first deployment 404'd it). - The protected migration workflow now sends compact JSON; the pretty profile exceeded the 128 KiB environment-variable limit (run `40539766394` failed before any change was applied). ### Evidence - `7d66ff4`, `ddc719c` (profile and demo data): build `40540374621`, demo population `40540374640`, migration `40541051298` all succeeded. - `76ca575` (packaging and CSS): build `40544414190`, migration `40544916996` succeeded. - Full PHPUnit suite (603 tests, run directly against the staging-cloned test database): the only failures are pre-existing at the previous HEAD, `testNestedPresentationObjectsUseIndependentContentLayout` and five in `Idy006GraphTest`. New tests cover the table, compact/`max_rows`, page-header partition and metric caption. `php -l`, `node --check`, JSON validity and `bin\target-check.php` pass. - Authenticated STAGING browser, 1536px: Finance shows a header, three KPIs (£48,000 / £9,550 / £85,100), tabs (All 11, Settled 5, Awaiting 2, Planned 4) and an 11-row table with badges, currency, dates and `/objects/{id}` row links; Products & Services shows 7 offerings (4 active, 2 planned, 1 retired) and Projects 8 projects with milestone progress 50%. Tab and search filtering work live (Settled 5 rows; `invoice` 2 rows) with no console or network errors. No horizontal overflow at 1536px or 375px. KPI content is vertically centred. - Layout editor on Finance: resize, save (`Layout saved.`), reload persisted the new height, and the original layout was restored and re-verified. The header exposes no drag or resize handle. ### Limitations - No Category, Price, Owner or thumbnail fields without a governed Type revision; no trends are fabricated. - Tab and search filtering is client-side; tab counts and `max_rows` are server-computed. - The former 192px editable-surface height floor was removed on 2026-10-28 (see the shared UI refinement section above); `preferred_height` is an optional floor of 1rem or more. - Marketing and Operations count filter vocabularies are inferred (they show 1 each). - Orphaned `*-page-body` Objects remain persisted. - `bin\run-tests.ps1` aborts on stderr noise for a full run; the suite was run directly with the same refreshed database. - Screenshot tooling in the embedded browser was unreliable (clipped viewport), so visual checks relied on DOM geometry, accessibility snapshots and a few screenshots. Pixel-level comparison with the references was not achieved; composition and density were compared structurally. ## STAGING development workflow and verified UI baseline - 2026-10-27 The latest UI restoration evidence was independently checked before changing the STAGING workflow. GitHub Actions metadata confirms successful completion of the protected target release `40508581471` (run `565`) for `ba2a6d7`, the read-only registration diagnostic `40519820127` (run `55`) for `822b7b5`, and the protected Presentation migration `40521104030` (run `23`) for `822b7b5`. The migration run settled the persisted Presentation root at revision `9` and reported the existing Presentation AuthorityGrant already settled at version `10`. These run records independently verify the recorded release, diagnostic and migration conclusions; they do not by themselves prove every browser assertion. The authenticated STAGING Dashboard at `https://platform-staging.idiosyncrasy.co.uk/objects/87c1954c-7810-445c-85dd-1bdc96a6f10f` was reachable during this change. A browser geometry probe measured a `1536px` viewport and `scrollWidth == clientWidth == 1536px`; the shared shell, Dashboard content and `Edit layout` control were present. The repository and current authenticated page do not independently reproduce the full four-page screenshot set, all mobile measurements or every saved editor operation, so those remain accepted from the recorded evidence rather than re-run here. The STAGING development path now removes the repeated manual migration dispatch: `staging-presentation-profile-migration.yml` retains explicit `workflow_dispatch` but also runs from `workflow_run` only after a successful `main` push of the `Build target release artifact` workflow. It requires the upstream event to be a push, checks the upstream repository and branch, and checks out the upstream workflow's exact commit SHA. The existing protected SSH transport, STAGING environment, concurrency group, database-identity checks, operator credential boundary and `extend-business-presentation.php` governed command remain in use. The migration no longer requires a manually copied AuthorityGrant version. The explicit allowlisted AuthorityGrant Object ID is still required; the CLI reads that grant's current version immediately before deciding whether an update is needed and uses the observed value as the CommandHandler expected version. A concurrent change therefore fails closed through the existing optimistic concurrency check rather than being overwritten. No direct SQL mutation, HTTP fallback, production credential or production path was introduced. The workflow and CLI changes are validated locally with PHP syntax checks, remote-shell syntax checks and `git diff --check`. The first automatic run (`40524450699`, run `24`) exposed and reported one stale CLI precondition before mutation: omitting the manual version input was still rejected by the old identity/revision guard. Commit `b4c3107` removed that stale guard while retaining current-version resolution and optimistic expected-version validation. The complete post-change development cycle then ran without a manual workflow dispatch. The exact `main` push at `b4c3107` produced target release/deployment run [`40524811555`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40524811555) (run `570`), with both artifact build and protected `deploy-staging` jobs successful. Its chained `workflow_run` automatically started protected Presentation migration [`40525222161`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40525222161) (run `25`) on the same `b4c3107` SHA; the migration validation, exact-source checkout and protected SSH execution all succeeded. The governed output reported `grant_reconciliation.status=already_settled`, AuthorityGrant version `10`, `presentation.status=already_settled`, and the persisted Presentation root `87c1954c-7810-445c-85dd-1bdc96a6f10f` at revision `9`. This demonstrates source change -> exact deployment -> persisted Presentation reconciliation through the authorized development path without a manual operator dispatch. The available Actions integration still has no workflow-dispatch operation. That is no longer a development blocker because the normal path is an authorized push to `main`, followed by the protected workflow chain; explicit manual dispatch remains available as a fallback for exceptional re-runs. ## End-to-end Presentation change propagation and revert - 2026-10-27 The automated path was exercised with one reversible source-defined Presentation change. The only test definition change was the generic profile's Dashboard container label, from `Dashboard` to `Dashboard - E2E`, in `database/configuration/idy-008/generic-business-presentation-profile.json`. The profile revision remained `9`; no layout, capability, authorization, schema or production configuration changed. The expected result was a changed Dashboard page title/heading in the generic renderer, with the existing navigation, workspace surfaces and editor controls unchanged. The source was then restored to `Dashboard` through a separate commit. Before the test, the authenticated STAGING browser rendered `Dashboard`; the Dashboard root was persisted at revision `9` and the AuthorityGrant was at version `10`. The test commit [`64d9571`](https://github.com/StuMayne74/Idiosyncrasy/commit/64d9571) triggered target release/deployment [`40527592006`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40527592006) (run `572`). Its logs recorded the exact deployment SHA `64d9571f96a2652ec879ad8c5ff1c4e5ba7eeced`, verified release `IDY-TARGET-0bb29c08a8071bb6ec1c1cd2090618728343cd027bd0633adc45847667a2d1c0`, `HTTP_VERIFICATION=PASSED path=/health` and `STAGING_DEPLOYMENT=ACTIVATED`. The chained protected migration [`40527938165`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40527938165) (run `27`) checked out the same SHA and reported a governed settled command `9121ca08-d2e7-4e04-912d-6148f0e53d85`, Presentation root revision `10`, and AuthorityGrant version `10`. This was a real reconciliation (`status=settled`), not an `already_settled` result. Authenticated browser verification after the test migration showed page title and H1 `Dashboard - E2E`. The generic Dashboard cards and workspace links remained present; `Edit layout` and `Inspect` remained available; viewport width and document `scrollWidth` were both `1536px`; and the changed result survived an authenticated browser reload. The browser session expired once during an initial reload after deployment and required the existing authorized user to sign in again; no credential was guessed or accessed by the workflow. The revert commit [`356265c`](https://github.com/StuMayne74/Idiosyncrasy/commit/356265c) restored the source label to `Dashboard` and triggered target release/deployment [`40528415964`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40528415964) (run `573`). Its logs recorded the exact revert SHA `356265c30d9245b70dffcf7a314c691aa9e6ad78`, `IDY-TARGET-14692874aec735e0f3b7468e5548ec6deb18f48f42deeeee0a709d837ac1a4d2`, `HTTP_VERIFICATION=PASSED path=/health` and `STAGING_DEPLOYMENT=ACTIVATED`. The automatic protected migration [`40528950206`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40528950206) (run `28`) checked out the revert SHA and reported governed command `974a500a-ce47-40ca-b706-2ce26c2d8f38`, Presentation root revision `11`, and AuthorityGrant version `10`. The final authenticated browser reload rendered `Dashboard` again, with the same generic surfaces and controls, no horizontal overflow (`1536px == 1536px`) and no observed layout regression. Both changes used the existing protected SSH migration and generic CommandHandler transaction/provenance/authority path. No direct database write, manual reconciliation or manual workflow dispatch was used. Local verification included JSON parsing and `git diff --check`; the target release and both protected migrations also passed their GitHub validation steps. `vendor\bin\phpunit` remains unavailable in this checkout, so PHPUnit was not run. ## Grouped capability overview surfaces and live acceptance - 2026-10-27 The post-release desktop screenshot exposed a remaining composition problem in the otherwise restored generic layout contract: the standalone capability roots selected icon and description primitives as separate page-level surfaces. The generic renderer correctly gave those primitives grid placement, drag handles and resize handles, but their sparse content produced visually empty cards. Commit `ba2a6d7` corrects the persisted Presentation graph without adding capability-specific rendering. The existing Products & Services, Projects and Finance & Accounts `*-page-body` container is now the page-level overview surface (`surface: true`, preferred span `4`, preferred height `16`). Its icon, summary and metric/progress/chart children remain nested content. The collection and navigation objects remain separate page-level surfaces. This preserves generic six-column packing, user positioning and governed layout preferences while removing the standalone sparse primitive cards. The Dashboard-card Presentation Objects and shared renderer are unchanged. The profile source validates as JSON, the grouped root/child graph was checked explicitly, and `git diff --check` passes. The focused PHPUnit test was updated but could not run because this checkout has no `vendor\bin\phpunit`. Target release [`40508581471`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40508581471) (run `565`) completed successfully for commit `ba2a6d7` and deployed the source profile to STAGING. A fresh registration diagnostic [`40519820127`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40519820127) (run `55`) completed successfully on `822b7b5` and confirmed the AuthorityGrant at version `10`. The protected Presentation migration [`40521104030`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40521104030) (run `23`) then completed successfully on `822b7b5`. Its protected command `cc7f873c-ac4a-426b-8f4c-648d55414096` settled the Presentation root at revision `9`; the migration log reported the grant as already settled at version `10`, with authorization and provenance checks intact. Authenticated live verification after migration confirmed the persisted graph through rendered object references, not source JSON alone: - Products & Services renders three direct surfaces: the grouped overview (`a7dcc3fc-059d-44c3-828c-28c349bf903e`) at `859x256`, the offering collection (`3de7265e-f249-4b4e-a8f5-2b196b4535c9`) at `859x288`, and the navigation surface (`1fad14fd-7fd3-4695-8721-95d2ffdff50f`) at `421x192`. - Projects renders three direct surfaces: grouped overview (`b0603073-5cfe-4fd8-b408-385128ded6ed`) at `859x256`, portfolio collection (`779fb958-89af-4bc9-9631-083e5a2b3637`) at `640x288`, and navigation at `640x192`. - Finance & Accounts renders three direct surfaces: grouped overview (`8091aea8-2496-4496-a34a-a013033db844`) at `859x256`, financial collection (`b8253fe9-ca75-4e19-b028-6a5353d334f7`) at `640x288`, and navigation at `421x192`. The overview surfaces contain their icon, summary and metric/progress/chart content inside the parent content grid; they do not render nested PO cards. Desktop content grids use the available three-column inner layout. The Dashboard continues to render `12` direct surfaces on its six-column grid. Desktop geometry checks report no horizontal overflow for all four pages. Fresh authenticated desktop and mobile screenshots were captured for Dashboard, Products & Services, Projects and Finance & Accounts and compared with the approved dashboard visual. At the approximately `375px` mobile CSS viewport, each affected page renders three single-column surfaces at `335px` width and reports `scrollWidth == clientWidth` (`375px`), with no horizontal overflow. The screenshots show the shared shell, heading hierarchy, grouped overview, populated collection and governed navigation card consistently. The generic editor was exercised on the affected pages: - Products & Services: edit mode exposed three drag handles and three resize handles. The overview was resized from span `4`/height `16` (`859x256`) to span `3`/height `12` (`640x192`), saved through the governed preference endpoint, and recovered with the same geometry after reload. It was then restored to span `4`/height `16` and verified again after reload. - Projects: edit mode reordered the overview and portfolio surfaces through drag-and-drop; the changed order persisted after save and reload, then was restored to the original order and verified after a second save/reload. - Finance & Accounts: the overview was resized from span `4`/height `16` to span `3`/height `12`, persisted and verified after reload, then restored to span `4`/height `16` and verified again. - Dashboard: the post-migration edit check exposed all `12` drag handles and `12` resize handles on its existing direct surfaces, saved with no changes, and reloaded without overflow or graph loss. No capability-specific renderer branch, CSS selector, persistence model or database mutation was introduced for this correction. The only remaining automated-test limitation is that this checkout has no `vendor\bin\phpunit` and no VS Code test controller; JSON parsing, graph-shape validation and `git diff --check` passed. ## Capability presentation, page roots and demonstrator expansion - 2026-10-27 ### Desktop grid regression correction The initial responsive verification covered the browser's narrow CSS viewport, but did not cover the authenticated desktop geometry shown in the approved reference. That exposed a generic CSS regression: the direct `.presentation-content-grid` child of the six-column `.presentation-elements` grid did not span the parent columns, so desktop capability content rendered in only the first `202px` track of a `1296px` content area. This caused the compressed Products & Services, Projects and Finance & Accounts screenshots and made the editing surface appear unusable. Commit `4e53019` added the generic `.presentation-elements > .presentation-content-grid { grid-column: 1 / -1; }` rule and advanced the stylesheet cache key to `dashboard-design-4`. Protected target release [`40503192698`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40503192698) (run `561`) completed successfully. A desktop browser geometry check after the correction measured the Presentation content grid at the full `1296px` content width with three `421px` columns. The existing editor wiring was also exercised on the Dashboard: the toggle changed to `Save layout`, added `12` drag/resize handles, and reported `Layout editing enabled.` No Presentation persistence operation was performed during this check. The bounded remediation is settled in STAGING. It uses the existing universal Object, Relationship, revision, provenance, authorization and Presentation contracts. No semantic Type, registry, route, capability-specific renderer branch or capability-specific CSS selector was introduced. The generic Presentation profile remains revision `9`. Existing dashboard-card Presentation Objects remain intact for dashboard use. Three separate governed page roots compose Products & Services, Projects and Finance & Accounts from the existing display vocabulary. Their dashboard cards contain exact `navigation.target` references to those roots. Generic heading resolution now uses persisted labels, nested Presentation Objects do not receive top-level surfaces, and narrow generic lists and relationship tables remain within their content boundary. The capability configuration is `generic-business-capability-configuration-v5`. The governed demo population was executed through the protected mechanism: `42` records were reconciled (`18` created and `24` already present), and `20` relationships were reconciled (`15` created and `5` already present). Existing records were retained. The live Finance metric `£102,900` is backed by the six reconciled financial records. The live Projects page shows `5` projects and milestone progress of `4 of 8 complete` (`50%`); its related record view exposes the governed Northstar milestones and assigned people. ### Protected workflow evidence All workflow runs below were confirmed by GitHub as completed successfully unless explicitly marked as a safe pre-mutation failure: - Source implementation: commit `1b1422f`, target release [`40487952369`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40487952369) (run `552`). - Presentation profile correction: commit `0342cc7`, target release [`40492303925`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40492303925) (run `554`). - IDY-008 snapshot and command-seed correction: commit `b65b56e`, target release [`40494152690`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40494152690) (run `555`). - Current Presentation dashboard-revision diagnostic correction: commit `32f35f0`, target release [`40494801190`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40494801190) (run `556`). - Generic list sizing: commit `4fa58f1`, target release [`40495787472`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40495787472) (run `557`). - Stylesheet cache invalidation: commit `7259a98`, target release [`40496343794`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40496343794) (run `558`). - Narrow relationship-table containment: commit `2ec702b`, target release [`40496989036`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40496989036) (run `559`). The fresh registration diagnostic [`40491891571`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40491891571) (diagnostic run `48`) validated AuthorityGrant `57956cd2-b52d-40c8-8031-720e5f06f06c` at version `10`, with authorization `GRANTED`, resolution `RESOLVED` and target contract `VALID`. The first profile migration attempt [`40492102390`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40492102390) (run `20`) failed safely before mutation because the six new nodes lacked the required integer `order`; commit `0342cc7` corrected the source. A fresh diagnostic [`40492827874`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40492827874) (run `49`) reconfirmed version `10`, and migration [`40492974297`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40492974297) (run `21`) settled with the Presentation root at persisted revision `8`. Diagnostic [`40493123967`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40493123967) (run `50`) completed successfully. The first demo-population attempt [`40493327059`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40493327059) (run `22`) failed safely because the generic capability configuration was drifted. Reconciliation attempt [`40493508042`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40493508042) (run `18`) then stopped safely on the stale Projects declaration. Read-only diagnostic [`40493685309`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40493685309) (run `19`) established the verified post-v4 STAGING baseline. Corrected reconciliation [`40494440309`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40494440309) (run `20`) settled People, Organisations, Projects, generic configuration and AuthorityGrant. Governed population [`40494566658`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40494566658) (run `23`) then completed the `42`-record and `20`-relationship reconciliation. Post-population diagnostic [`40495398870`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40495398870) (diagnostic run `52`) inspected the persisted Presentation reference from the Business Object rather than a historical hardcoded revision. It verified root `87c1954c-7810-445c-85dd-1bdc96a6f10f` at revision `8`, `64` bounded graph edges, all `64` references authorized and resolved, and render smoke `SUCCEEDED`. AuthorityGrant remained at version `10` with `GRANTED`/`RESOLVED` authorization evidence and a `VALID` target contract. ### Authenticated STAGING browser evidence After release `559`, authenticated reloads of the three page roots used the persisted STAGING graph and the governed records: - [Products & Services](https://platform-staging.idiosyncrasy.co.uk/objects/4e479302-8af3-4475-9d83-7c51e5432f0e) rendered four offerings and the `Active offerings: 4` metric. - [Projects](https://platform-staging.idiosyncrasy.co.uk/objects/5fe5e1fe-e483-4f8c-b846-0c928adc5d8b) rendered five portfolio projects, `Active projects: 5`, and `4 of 8 complete` milestone progress. - [Finance & Accounts](https://platform-staging.idiosyncrasy.co.uk/objects/05f1e0b7-291e-4e53-b973-33e93765c630) rendered six financial records, the financial chart and `Recorded value: £102,900`. Comparable authenticated screenshots were captured for the dashboard and all three page roots after reconciliation and population. At the browser's actual narrow CSS viewport of approximately `518px`, final reload checks reported: | Page | `bodyScrollWidth` | `bodyClientWidth` | Result | |---|---:|---:|---| | Products & Services | 518 | 518 | No horizontal overflow | | Projects | 503 | 503 | No horizontal overflow | | Finance & Accounts | 503 | 503 | No horizontal overflow | | Northstar Project relationships | 503 | 503 | Table scroll remains internal | The Northstar relationship view retained four governed Milestones and four People/People-assigned endpoints, including Alex Morgan, Jordan Lee and Riley Shah. Workspace links from all three page roots navigated to their authorized typed collections and returned successfully after reload. The authenticated checks did not mutate data, bypass authorization or access production. Source validation passed for JSON parsing, Presentation node shape validation, PHP syntax and `git diff --check`. The prescribed PHPUnit runner remains blocked before test execution in this local environment because `IDY_TEST_DB_HOST`/the disposable MariaDB service is unavailable; no local test result is represented as a passing PHPUnit run. Empty-state rendering continues to use the generic renderer, but no safe live operation was used to remove governed STAGING records solely to manufacture an empty capability page. The implementation and protected STAGING evidence for the bounded capability page remediation are complete. Historical entries below retain their original observations and dates. ## Scope and Evidence Rules Snapshot date: 2026-10-25. This document owns the current implementation evidence snapshot and reuse disposition, not architectural definitions or release scope. Historical evidence dates below remain the dates of those observations. Separate architecture approval, implementation presence and behavior verification; none implies the others. The final D01-D10 architecture and initial implementation specification are documented. This does not make the new platform implemented or verified. The old application has no required data continuity, API compatibility or feature-parity obligation. This snapshot records the canonical focused and full-suite evidence listed below; it does not claim browser, deployment or security certification. The verified test runner is `.\bin\run-tests.ps1` and the bounded runtime uses PHP 8.3.33, PHPUnit 11.5.56 and isolated MariaDB 10.5.26/InnoDB fixtures. There is no general worker or module runtime. Use [documentation governance](../governance/documentation.md) for workflow and [source map](../governance/source-map.md) for source-to-successor coverage. ## Protected Presentation profile migration - 2026-10-26 The protected migration was dispatched through the existing `staging-presentation-profile-migration.yml` workflow using the freshly validated STAGING AuthorityGrant version. The read-only diagnostic was run immediately before dispatch in [`40318982772`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40318982772) (diagnostic run `45`) and returned: - AuthorityGrant `57956cd2-b52d-40c8-8031-720e5f06f06c`: current version `10`; - authorization `GRANTED`, resolution `RESOLVED`, target contract `VALID`; - Principal `c92ebd13-d57e-48c8-b4df-f5171598e91a` and Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275` selected by the diagnostic. Migration run [`40319138600`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40319138600) (run `19`) completed successfully on `main` at commit `68dd40dab14bfb953222c62419d5c0de85a030a6`. Its governed result was `status=settled`, `grant_reconciliation=already_settled` at version `10`, and the Presentation root `87c1954c-7810-445c-85dd-1bdc96a6f10f` was reconciled at revision `7`. The independent post-migration diagnostic [`40319275980`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40319275980) (diagnostic run `46`) also completed successfully. It confirmed the same AuthorityGrant version and valid authorization, a read-only graph with `25` exact references, rendered status `SUCCEEDED`, and all `25` references `GRANTED` and `RESOLVED` with no rejection. The shared browser pages are currently unauthenticated, so authenticated visual acceptance, screenshots against the approved dashboard reference, and record-level browser traversal remain unverified. ## Dashboard regression correction - 2026-10-26 The previous dashboard release exposed two defects that are now corrected in the current working tree. First, the dashboard CSS used a dark purple sidebar, which contradicted the approved light Pastel SaaS reference and the intended light-shell delivery. The sidebar tokens, background, active state and hover state have been restored to the light visual system; the stylesheet cache version remains so the correction is deliverable through the normal release path. Second, repeated records were rendered by the generic fallback as a text-heavy container with an unconditional underlined `Open record` link, followed by every child and nested collection. The canonical profile now declares a generic `record_summary` display with persisted child roles (`primary`, `body`, `secondary` and `status`). The renderer uses that declaration to create a compact summary surface, renders ordinary values as text, emits only an exact-target icon action, and suppresses child collections declared for `detail` context while a record is summarized. No Project, Milestone or capability-specific renderer branch was added. Focused verification after the correction: - Dashboard renderer and record-summary regression tests: **16 tests, 78 assertions, 0 failures**. - Profile contract tests: **7 tests, 72 assertions, 0 failures**. - Combined renderer, profile, Presentation integration and installer suites: **93 tests, 660 assertions, 0 failures**. The fixture still emits the existing non-fatal `Inspection is not authorized` diagnostics; stderr was suppressed for the final exit-status check and PHPUnit completed successfully. - PHP lint, profile JSON parsing and `git diff --check`: passed. The correction was released to STAGING through protected target release run [`40317455685`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40317455685) (run `549`) from commit `c9492a8afe80c6d1df532958dbc2e5c56ba7cee2`. Both `build-target-release` and `deploy-staging` completed successfully. The protected revision-7 profile migration remains pending because the available GitHub integration does not expose workflow dispatch. The current shared browser session is unauthenticated after release, so no authenticated post-release screenshot or persisted revision-7 verification is claimed here. ## Approved dashboard design build - 2026-10-26 The approved Pastel SaaS Business Dashboard reference is now expressed by generic, data-defined Presentation Objects rather than a dashboard-specific template. The design-to-PO mapping and display contract are recorded in [ui-system.md](ui-system.md) and [Views and Content](../architecture/views-and-content.md). The generic profile is revision `7`. It adds a persisted page header, date range control, three KPI compositions, eight differentiated capability surfaces, authorized record summaries, avatar groups, progress, bounded current-value charts and an explicit informational callout. It does not copy sample image values, invent trend history or fabricate media. The projector derives display data only through the authorized object reader, selects declared fields, bounds the source page size and preserves available, unavailable and invalid-source states. Explicit persisted navigation targets remain the only links; display values remain text. The generic renderer owns HTML, accessibility, responsive layout and styling, with no capability, Project or Milestone conditionals. Implementation commits: - `0fcb009` — generic display projection, profile revision `7`, renderer, shell, CSS, documentation and regression coverage. - `3d6e342` — protected migration workflow default aligned to profile revision `7`. - `6709e48` — stylesheet cache-busting version for the new STAGING delivery. The protected target release for `6709e48` completed successfully as run [`40310903120`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40310903120); both the artifact build and `deploy-staging` job completed successfully. Authenticated STAGING at `https://platform-staging.idiosyncrasy.co.uk/` now shows the cache-busted search/header shell and the prior deployed navigation. The persisted Business Presentation graph is still the previously migrated revision `6`, so the new KPI and capability display graph is not yet a claim of live browser acceptance. Verification completed against the refreshed isolated database: - Dashboard/profile renderer tests: **22 tests, 137 assertions, 0 failures**. - `Idy006BPresentationTest`: **48 tests, 381 assertions, 0 failures**. - `Idy008InstallerTest`: **22 tests, 129 assertions, 0 failures**. - Combined relevant Presentation/provisioning run: **100 tests, 687 assertions, 0 failures**. - PHP lint, profile JSON structure validation and `git diff --check`: passed. The integration fixture emitted existing non-fatal `Inspection is not authorized` workflow diagnostics while PHPUnit still completed successfully. The protected migration remains pending. The inspected `staging-presentation-profile-migration.yml` requires Principal `c92ebd13-d57e-48c8-b4df-f5171598e91a`, Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275`, AuthorityGrant `57956cd2-b52d-40c8-8031-720e5f06f06c`, profile revision `7` and a freshly validated AuthorityGrant expected version. The available GitHub Actions integration exposes workflow inspection, run listing and logs but no workflow-dispatch operation. No migration was dispatched, no stale grant version was reused, and no direct database or SSH mutation was attempted. Consequently there is no new migration run ID or persisted revision-7 verification yet; authenticated visual acceptance of the new dashboard must remain pending that single protected operator action. ## Generic Presentation design-system conformance - release and protected-migration boundary The current design contract maps the light workspace and rounded surface mechanisms in `ui-system.md` to persisted Presentation Objects as follows: dashboard and capability surfaces are outer Presentation containers; capability titles, summaries and navigation are ordered child Presentation Objects; summaries are embeddable-only text nodes; and navigation is an explicit Presentation target rather than an inferred property of an Object. Nested records remain collection-context summaries, while standalone records retain their own surface and navigation contract. Outer layout spans and responsive reflow remain governed by the existing six-column preference mechanism. The generic profile now declares summaries for all eight capability cards, with navigation remaining the explicit final child. The renderer delivers navigation through a compact accessible affordance class, keeps ordinary explicitly non-navigable values as text, and preserves the neutral nested record/collection boundaries introduced by `395abbd` and `9da6f75`. No capability-specific rendering branch or business-type selector was added. Final validation on the refreshed disposable `IDY_TEST_IDY002` snapshot: - Focused Runtime Presentation and profile tests: 20 tests, 129 assertions, 0 failures. - Final Runtime Presentation, relationship-backed Presentation and profile regression suites: 76 tests, 550 assertions, 0 failures. - PHP lint, profile JSON parsing and `git diff --check`: passed. - Existing non-fatal `Inspection is not authorized` workflow diagnostics continued during integration fixture setup; PHPUnit exited successfully. Commit `3e671eb` was pushed to `origin/main` and released to STAGING by the protected application workflow as run `40199908615`. The release contains the generic reconciliation correction that rebases `binding.record_template` references to the reconciled record-template revision. The root cause was that ordinary child references were rebased while relationship collection bindings continued to point at stale record-template revision `1`; the source profile therefore declared an explicit target that the live projected template did not expose. The protected `staging-presentation-profile-migration.yml` workflow was then executed on `main` at commit `3e671eb` as run [`40200381415`](https://github.com/StuMayne74/Idiosyncrasy/actions/runs/40200381415). The workflow and its migration job completed successfully. Its governed output reported `status: settled`, Principal `c92ebd13-d57e-48c8-b4df-f5171598e91a`, Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275`, AuthorityGrant `57956cd2-b52d-40c8-8031-720e5f06f06c` already settled at expected version `10`, command ID `6e492c9d-b8b4-44d6-ae4b-7f6fabe9415c`, and the generic Presentation root `87c1954c-7810-445c-85dd-1bdc96a6f10f` at profile revision `6`. The workflow checked out the selected commit, validated the migration sources, and executed only through the protected SSH path. Post-migration inspection and authenticated browser verification at `https://platform-staging.idiosyncrasy.co.uk/` confirmed that the persisted Project collection now projects the reconciled record-template targets. The Northstar Project view shows both Milestones and Alex Morgan under People assigned, with exact `Open record` links to each intended Object. The first Milestone link and the Alex Morgan link opened their intended object views without a 404, blank page or authorization failure; refreshing both views preserved their content and relationships. People lists actual records, Projects lists Northstar and the other authorized projects, and the Dashboard shows all eight capability cards with summaries and compact explicit navigation affordances. The existing Dashboard layout editing controls remain available and were not regressed. A captured STAGING screenshot showed the light workspace, rounded surfaces, three-column composition and compact navigation treatment. No unresolved view-revision limitation was observed on the accepted People, Project, Milestone or Person routes; exact persisted object and Presentation references remain authoritative. ## Nested Presentation collection delivery - design-led verification The canonical Views/Content and UI contracts require a nested repeated record to be delivered as a summary in its collection context, not as a second standalone surface. Its field values remain ordinary text unless an explicit projected target is present, and a nested collection owns its internal record list rather than inheriting the containing surface's content columns. The first generic renderer implementation had two defects: a container-level `record_object` target wrapped the recursively rendered fields in an anchor, which created nested-anchor semantics and underlined every descendant value; and nested repeated records received standalone surface treatment. The correction in `395abbd` delivers an explicit accessible `Open record` link for container targets, keeps ordinary field values unlinked, and uses neutral `presentation-record` summaries. Live STAGING inspection then established a second generic layout defect: the collection itself was allowing the outer content grid to constrain its record list. Commit `9da6f75` adds a neutral `presentation-collection` boundary whose internal record list is full-width and single-column while preserving each record's own persisted presentation mode. Focused evidence on the approved refreshed disposable `IDY_TEST_IDY002` snapshot: - Runtime Presentation suite: 21 tests, 104 assertions, 0 failures. - Relationship-backed Presentation integration: 48 tests, 370 assertions, 0 failures. - PHP lint and `git diff --check` passed. - The integration suite emitted the existing non-fatal `Workflow event dispatch failed ... Inspection is not authorized.` messages; PHPUnit still exited successfully. Commit `9da6f75` was pushed to `origin/main` and deployed to STAGING through the protected release workflow as run `40196409073`; the run completed successfully. Browser acceptance was performed only at `https://platform-staging.idiosyncrasy.co.uk/` after refreshing the deployed page. Projects rendered Northstar Commerce, both Milestone summaries and one Alex Morgan entry. The live DOM showed no nested anchors and no nested standalone surface classes; the nested collection summaries occupied the collection's full-width internal flow rather than the prior approximately 90px tracks. The authorized Relationships view exposed exact links to `51f96600-3b1c-4ab9-b12a-6edb6aa01e39` and `416832b7-35b0-45d5-b978-f50ebe2f3fbf`; the first link opened the intended Project Milestone view and a browser refresh preserved its content. The current persisted/projected Milestone record-template instance did not expose an inline `record_object` target in the authenticated Project DOM, although the repository profile declaration contains that target. This is a remaining persisted Presentation reconciliation discrepancy, not a renderer fallback: no inline Milestone link is claimed. Direct record navigation is verified through the authorized relationship route, which preserves exact Object identity and existing authorization. Resolving the persisted template discrepancy requires the existing protected Presentation migration with a freshly revalidated AuthorityGrant version; no direct database mutation or authority bypass was used in this release. This paragraph records the pre-migration observation and is superseded by the settled migration and post-migration evidence in the current conformance section above. ## Adaptive Presentation span delivery - focused verification The current implementation preserves revision-2 generic User Presentation Preference Objects and persists only direct outer Presentation Object order, span and height. The six-column `LayoutPackingEngine` applies only to the current page-surface list. Recursive descendants receive no outer row, position or span metadata and render inside their parent `presentation-content-grid`. Presentation mode and internal content columns are derived delivery metadata: persisted outer spans are restricted to 2, 3, 4 and 6; span 2 is Regular/two columns and spans 3, 4 and 6 are Expanded/three columns. Responsive CSS may still reflow a surface to one visual column at narrow widths. There is no `preferred_content_columns` property, migration to revision 3, or user-facing Content columns selector. Responsive CSS may reduce the effective internal count without mutating the saved outer preference. The governed demonstrator population now includes Alex Morgan, Jordan Lee and Riley Shah, Northstar Commerce, their project relationships and the existing cross-capability records. It remains deterministic and idempotent through `SpearmintDemoPopulationService`; generic newly-created Businesses are not populated with these records. Focused evidence completed on an approved refreshed disposable `IDY_TEST_IDY002` snapshot: - Renderer/packing regressions: 13 tests, 75 assertions. - Presentation integration suite: 41 tests, 331 assertions. - Governed demo population/idempotence: 1 test, 43 assertions. - The pinned runtime is PHP 8.3.33, PHPUnit 11.5.56 and MariaDB 10.5.26. The repository runner emits the known non-fatal `Inspection is not authorized` workflow diagnostic on STDERR during fixture setup; the PHPUnit exit status and assertions above passed. Protected STAGING release and browser acceptance for this uncommitted adaptive implementation are not claimed by this entry. The earlier revision-3 preference implementation and its STAGING HTTP 409 remain historical evidence below. The owner decision superseded that selector model; the protected Stage-3D Type-revision migration remains unauthorized. ## Project relationship collections — implementation and protected-STAGING boundary The generic Presentation projector now supports an explicit `object_collection` source backed by an exact relationship Type, direction, target Type, target View and record-template reference. It reuses the authorized relationship reader, preserves endpoint Object identity and revision, and fails closed for stale, unauthorized, cross-Business or incompatible references. The Projects profile revision is `6`; its Project record template composes embeddable-only Milestones and People-assigned collections. Tasks and Deliverables remain unconfigured because no authoritative records were established for them. The current authenticated STAGING Business is `a20d5b62-078c-4ef4-b0ce-41027f9bc275`. Its existing Project graph uses the same deterministic Presentation Object identities as the generic profile: Project root `6f87ead0-1145-48d2-b7a0-a9c5ec78e182` revision `2`, Milestone template `109f8124-9da6-49ad-b64a-df4d23976fe8` revision `2`, and Person template `137d4bca-722e-40cd-99f5-4760e1ff2f1b` revision `2`. The authorized Northstar Project has two Milestones and Alex Morgan through the assigned relationship. Before reconciliation, the Project detail showed only its four existing fields, as expected. Local verification after the implementation passed: - Presentation, relationship-projection and layout regressions: 57 tests, 451 assertions, 0 failures. - Spearmint population and initialization regressions: 2 tests, 43 assertions, 0 failures, 1 pre-existing skip. - PHP syntax, profile JSON and `git diff --check` passed. - The known non-fatal `Inspection is not authorized` workflow diagnostic was emitted during test setup; PHPUnit exited successfully. Commit `a9562a9` was deployed to the protected STAGING environment through GitHub Actions run `40094259310`; both the artifact build and `deploy-staging` job succeeded. The subsequent governed Presentation reconciliation was dispatched as run `40094551338` with the established STAGING Business, Principal and authority grant, but stopped before mutation with `CLI authentication failed`. No Presentation reconciliation or browser acceptance is claimed. The protected operator credential must be repaired before rerunning that workflow; direct database mutation and local target execution remain prohibited. Follow-up protected runs `40102073599` and `40102272799` used the same intended commit (`f941395`), Business, Principal, authority grant and expected profile revision. Both independently failed at the same `requirePrincipal()` CLI authentication boundary before any mutation. The latest authenticated browser inspection, after restoring the shared session on `https://platform-staging.idiosyncrasy.co.uk/`, still shows the Project root at revision `2` with only the four existing field children; the relationship-backed Milestone and People-assigned children are therefore not yet persisted or browser-verified. After the protected `staging` environment's `IDY_OPERATOR_PASSWORD` was repaired, run `40182426326` authenticated the established Principal successfully and reached the governed preflight. It then stopped before mutation with `The expected Presentation authority grant revision is unavailable.` The workflow was still using expected grant version `7`; this does not prove the current persisted grant version and must not be changed by guesswork. The next required action is an authorized, read-only inspection of the current grant identity, Business scope and version, followed by a single workflow retry only when that expected-version input is revalidated. No Presentation reconciliation or browser acceptance is claimed. The protected read-only diagnostic enhancement was published in commit `80d0156` and completed successfully as run `40184669161` (job `121142814850`). It established the following live STAGING facts without mutation: grant `57956cd2-b52d-40c8-8031-720e5f06f06c` exists with AuthorityGrant Type `1b107cd4-6d04-4a16-91a6-2435c5f75911` revision `4`, is Business-scoped to `a20d5b62-078c-4ef4-b0ce-41027f9bc275`, and has current object version `10`. Exact resolution for Principal `c92ebd13-d57d-48c8-b4df-f5171598e91a` was `RESOLVED` with authorization `GRANTED`. Its 47 target references all exist and the target contract is valid; the User Presentation Preference Type reference `8c4f6b8c-3d2e-4f10-8a11-223344556692` is present at revision `2`, matching its current version. Seven historical Type references have revisions older than their current Type-object versions, but the migration preflight only requires their exact reference shape and does not reject those historical references. Therefore the exact cause of run `40182426326` is the stale workflow expected grant version `7`; the revalidated expected version is `10`. Reconciliation remains unattempted after this diagnosis, and no Presentation graph or production state was changed. The protected migration was subsequently rerun against commit `de97505` with expected grant version `10` as run `40187250812`. Authentication and authority preflight succeeded; grant reconciliation returned `already_settled` at version `10`, and the governed Presentation command returned `settled` with command `b1f2b2ca-5c0a-4b7e-ba3d-bf3799344cb3`. The existing Dashboard root `87c1954c-7810-445c-85dd-1bdc96a6f10f` advanced to revision `5` in place. The persisted graph output includes the deterministic Project root `6f87ead0-1145-48d2-b7a0-a9c5ec78e182`, Milestone collection `d9935d4f-afc3-4e15-8fc1-38b265b87dbd`, People-assigned collection `c634a823-5e37-429c-8798-b6f859e467bf`, Milestone template `109f8124-9da6-49ad-b64a-df4d23976fe8` and Person template `137d4bca-722e-40cd-99f5-4760e1ff2f1b`; no parallel Project graph was created. The workflow also emitted a non-fatal `Workflow event dispatch failed ... Event subject is not available in the active Business context` diagnostic, but the governed command settled and the job succeeded. Authenticated browser acceptance is still pending: the shared STAGING browser session expired and redirected to `/login` before the Projects route could be opened. The persisted reconciliation is verified by the protected workflow output, but inline Milestone rendering, the single People-assigned Alex Morgan entry, refresh behavior and layout acceptance are not claimed until the operator restores the authenticated session. The final evidence commit `870d523` was built and deployed to STAGING successfully by release run `40187371201` (build and `deploy-staging` jobs both passed). Authenticated browser acceptance was completed on `https://platform-staging.idiosyncrasy.co.uk/` after the shared session was restored. The Projects capability view opened the authorised Projects workspace and listed three records, including `Northstar commerce launch`. The Northstar Project view rendered its existing name, objective, scope and active status, both authorised Milestones (`Discovery and positioning approved` and `Identity system ready for build`) and the single People-assigned entry `Alex Morgan`. The Project's persisted `View relationships` route exposed exact links for both Milestones and Alex Morgan; each opened its authorised object view without a 404, blank page or authorization error. Alex Morgan's relationship view exposed Northstar commerce launch and Northstar Commerce. The Project view was reloaded successfully with its fields and embedded collection content preserved. The rendered post-reconciliation DOM independently confirmed the persisted Project Presentation root `6f87ead0-1145-48d2-b7a0-a9c5ec78e182` at Object revision `3`, the authoritative Project View revision `4`, and revision `1` for the Milestone record template `109f8124-9da6-49ad-b64a-df4d23976fe8` and Person record template `137d4bca-722a-40cd-99f5-4760e1ff2f1b`. The protected migration output remains the evidence for the in-place collection node identities `d9935d4f-afc3-4e15-8fc1-38b265b87dbd` and `c634a823-5e37-429c-8798-b6f859e467bf`. The empty STAGING Acceptance Project rendered its own fields and controls without empty-collection errors. Dashboard rendered all eight capability workspace links. Dashboard `Edit layout` entered layout-editing mode and was reloaded without saving or changing layout preferences. No unexpected HTTP or rendering errors were observed during this acceptance pass. The acceptance was performed against the release deployed by run `40187371201`; the later status-only evidence commit was then pushed as `20f7cd1` and deployed successfully by release run `40187623120`. ## Presentation composition and display scope — approved contract The composition audit established that the existing generic mechanism already supports exact Business-scoped Presentation Object identity and revisions, explicit `children[]` composition, authorized recursive projection, collection record templates, cycle rejection and one generic renderer. It does not, however, persist independent-display eligibility. `presentation_surface` is derived from the delivery entry point, `navigation.navigable` controls only primary navigation, and graph placement alone cannot distinguish a standalone-only object from an embeddable-only object. The owner-approved correction is one constrained `display_scope` value on the persisted Presentation Object declaration: `standalone_only`, `standalone_and_embeddable` or `embeddable_only`. Legacy objects with no value retain current behavior through a compatibility interpretation of `standalone_and_embeddable`; new profile declarations must state the value. Independent page-level references are filtered by scope, whereas explicit parent composition still renders authorized embeddable children. Provisioning rejects standalone-only composition edges and embeddable-only independent roots. No Type revision, preference revision, parallel registry, direct database mutation or STAGING operation is authorized by this contract. The implementation conformance gate is generic: tests must cover all three scope values, nested composition without dashboard duplication, direct-route filtering, exact revision and Business/authorization boundaries, cycle handling, idempotent provisioning and unchanged adaptive outer layout. This section records the approved contract; runtime implementation and protected STAGING acceptance remain separate evidence. Protected release evidence for this increment: - GitHub Actions run `39964127248` built and deployed commit `7f3d112` through the protected `staging` environment; both build and deployment jobs passed. - Authenticated browser verification used only `https://platform-staging.idiosyncrasy.co.uk/`. - Dashboard rendered eight independent PO surfaces; two delivered `presentation-mode-expanded`/three-column content and six delivered `presentation-mode-regular`/two-column content. No Content columns selector was present. - People and Projects Presentation routes opened without 404 or authorization failure, but their record lists were empty because the governed `staging-spearmint-demo-population` workflow was not dispatched in this environment. No direct STAGING mutation or database bypass was used. - `GET /health` returned `runtime=target`, `status=boundary_ready`, `database_configured=true`, `database_connected=true` and `mutation_routes=[]`. The approved `php bin/runtime-migrate.php --database=staging` path was run with explicit authorization. Runtime migrations were already current, but the governed platform reconciliation failed closed on the existing persisted View Definition Type `8a4f6b8c-3d2e-4f10-8a11-223344556690`, whose revision-2 Stage-3D state conflicts with the historical revision-1 vocabulary expected by the current installer. The documented Stage-3D owner decision records that Type-revision migration as not authorized. No STAGING data was changed by this failed reconciliation, no direct SQL or in-place Type rewrite was used, and final save/refresh acceptance remains blocked at this authority boundary. ## Presentation display-scope implementation and STAGING evidence — 2026-10-23 The approved generic display-scope implementation is present in commit `0c431e0`. It retains exact Presentation Object references, recursive composition, authorization, Business scope, revisions and adaptive outer layout. Focused verification passed: - 58 tests and 405 assertions across display-scope, projector, renderer, profile and dashboard integration suites. - Governed demonstrator population/idempotence: 1 test and 43 assertions. - PHP syntax, profile JSON and patch-integrity checks passed. - The known non-fatal fixture diagnostic remains `Inspection is not authorized`; PHPUnit completed successfully. Protected GitHub Actions run `39968800640` built, verified and deployed the runtime commit through the protected `staging` environment. The follow-up evidence-only commit was built and verified in run `39969850811`; its deploy job installed the exact package but the final health-check request transiently returned HTTP 403, so that run is not recorded as a successful deployment. The subsequent direct health check returned HTTP 200 with `runtime=target`, `status=boundary_ready`, `database_configured=true`, `database_connected=true` and `mutation_routes=[]`. Authenticated browser checks used only `https://platform-staging.idiosyncrasy.co.uk/`: - People listed two authorized records, and Alex Morgan opened successfully. The exact relationship view exposed Northstar Commerce and two project records, each with valid object links. - Projects listed three authorized records, and Northstar commerce launch opened successfully. Its exact relationship view exposed two milestones, Alex Morgan as an assigned person and Alex Morgan as a related person. - The dashboard rendered all eight capability surfaces. Layout editing entered edit mode, saved successfully and preserved the dashboard content after refresh. The three explicit display-scope states have not yet been browser-verified against migrated STAGING Presentation Objects. Existing STAGING Presentation Objects omit `display_scope` and therefore exercise the documented `standalone_and_embeddable` compatibility behavior. The protected `staging-presentation-profile-migration` workflow is the authorized path to reconcile the revision-5 profile and create the explicit representative scope declarations; no direct database mutation or bypass was used. Its dispatch was not available through the current Actions tool boundary, so embedded-only suppression, explicit embedded-child rendering and direct-route rejection remain pending that governed migration. ## Presentation Object architecture audit - 2026-10-22 The Presentation Object lifecycle and layout contract were audited against the canonical architecture documents, the committed runtime at `e0e7b7b`, the persisted demonstrator profiles and the focused Presentation tests. No application code, business data, database or STAGING environment was changed for this audit. The verified architecture remains the universal Object/Type/Revision model: Business presentation configuration binds an exact Dashboard Presentation Object; recursively persisted child Presentation Objects retain exact identity and revision; governed provisioning validates containment and cycles; the authorized projector produces `RenderablePresentation`; and the generic HTML renderer serializes that authorized representation. Presentation Definitions and business Objects remain authoritative for structure and values respectively. The verified layout implementation is limited to the outer six-column page-surface grid and governed order/span/height preferences. The audit found that the committed projector recursively reapplies the outer packing engine and that the generic template/CSS uses `record-grid` for recursive content. The committed generic preference Type is revision 2 and has no internal one-/two-/three-column preference. Existing renderer tests include an assertion that nested Presentation Objects use the six-column grid; that assertion is now classified as a contract mismatch rather than a regression target. The canonical target contract now separates page-surface packing, each PO's generic surface, independent internal content layout and responsive adaptation. A future implementation must correct the shared generic path, select an authorized preference mechanism before adding a Type revision, and add semantic conformance coverage for exact identity, authorization, containment, nested rendering, independent layout, responsive persistence and empty-versus-suppressed projection outcomes. This entry does not authorize that implementation or a STAGING mutation. ## Final STAGING browser acceptance — 2026-10-22 The generic record-list navigation fix was released from commit `b2717028524f57bd30d0000c8f62a594b391d967`. The protected target build and STAGING deployment completed in run `39835049646`, followed by the governed Presentation profile migration to revision `5` in run `39835730031`, using the verified Presentation authority grant version `9`. Production was not changed. Authenticated browser acceptance was completed at `https://platform-staging.idiosyncrasy.co.uk/` in the Spearmint Design Business. The People list exposed two persisted Person records and the Projects list exposed the persisted Project records. Alex Morgan opened successfully and its relationship view linked to the exact Northstar Commerce Organisation and Northstar commerce launch Project objects. The Project detail opened successfully and its relationship view linked to both persisted Project Milestones and Alex Morgan; a milestone detail opened and rendered its persisted fields. The six remaining authoritative capability collection routes each exposed their persisted primary record and exact object-detail link, and each tested detail view rendered configured values: - Products & Services — Brand and digital launch. - Sales — Northstar Commerce referral. - Marketing — Northstar launch story. - Operations — Client delivery workflow. - Finance & Accounts — project budget. - Knowledgebase — Northstar launch decision record. The final persisted inventory remains 27 meaningful records with complete current revisions: People `2`, Organisations `1`, Offering `1`, Sales `5`, Marketing `5`, Operations `5`, Projects `3`, Project Milestones `2`, Financial `1`, Knowledgebase Items `1`, and Knowledgebase Assertions `1`. The five persisted relationship endpoints are complete: one Person–Organisation, one Person–Project, two Project–Milestone and one Project–Person relationship. Dashboard editing was verified at desktop viewport width: the persisted dashboard rendered a six-column grid, each card initially occupied at least two columns, drag and resize controls were present, a card was resized to three columns, Save layout reported success, and reload preserved the three-column span. The final reload showed no browser console or failed request event. A single exploratory request using a non-authoritative, manually guessed Type ID returned 404; no link emitted by the persisted Presentation graph used that ID. The original empty collection symptom was therefore a generic projection defect, not missing demo records or authorization. Provisioning had persisted Business-scoped runtime Type references while the list boundary compared only portable declaration IDs, and record templates lacked a generic `record_object` target. The fix matches both governed reference forms and adds exact record targets without capability-specific rendering. ## Project management increment — local implementation pending protected release The next increment extends the existing generic mutation and Presentation contracts without adding a Project persistence model. Generic transitions now resolve a current State Definition from either `value.state_id` or a data-defined `value.status` code and preserve that representation on the governed revision. The generic Project capability manifest adds the Business-scoped `planned`, `active` and `completed` State Definitions, `planned -> active` and `active -> completed` Transition Definitions, and state-specific persisted Form/action bindings. The manifest is release `generic-business-capability-configuration-v3` with digest `ab856341de92e41701af43733c4ec0f8c45fed41538a9c96525436fd00500ed8`. The authenticated generic object detail surface now exposes a reusable relationship-assignment form for configured relationship sections. It lists only authorized records of the exact counterpart Type, captures exact current endpoint versions, and submits one governed `object.relate` Command. It does not implement a Project-specific store or renderer. Project creation/editing continues to use the existing generic Object form and Command path; revision and provenance evidence remain available through the existing history and Command views. Local verification completed before release: - `Idy005MutationTest.php`: 49 tests, 196 assertions, including a status-backed transition and the existing `state_id` transition path. - `Idy006BPresentationTest.php` plus `BusinessPresentationProfileTest.php`: 42 tests, 336 assertions. - `Idy008InstallerTest.php`: 22 tests, 129 assertions, including the v3 manifest binding and idempotent installation. - `SpearmintDemoPopulationTest.php`: 1 test, 42 assertions. - PHP syntax checks and `git diff --check` passed. The protected release and authenticated STAGING Project journey are not yet verified in this snapshot. In particular, milestone creation is available through the existing generic Object form, but an atomic create-plus-relate milestone action and browser evidence for lifecycle transition and relationship assignment remain release acceptance work. Production remains untouched. ## IDY-008 v4 Presentation correction — local implementation pending protected release Authenticated STAGING verification after successful reconciliation run `39851368718` opened the Projects collection and a persisted Project detail, but no lifecycle action was rendered. The persisted v3 configuration showed the two `object.transition` action elements under the People View declaration `a2000000-0000-4000-8000-000000000001`; the Projects View declaration `a2000000-0000-4000-8000-000000000003` had no action elements. This is a Presentation declaration placement defect, not an authorization, routing or Project-data defect. The v4 manifest moves both state-specific action elements to the Projects View, leaves People without Project lifecycle actions, and retains the existing exact Project target Type and Form references. The protected reconciliation snapshot now describes the actual post-run STAGING state: People version `4` with the previously installed v3 value, and Organisations and Projects version `3` with the v2 values. The v4 trusted manifest digest is `d35b3f042a2202e7227ca89c38163d8fb0bfbb0eb337c447ba8da2261c145124`, and the reconciliation Command seed advances to v3 while recognizing v1 and v2 evidence for safe retry. Local focused verification is complete: the snapshot placement suite passes 3 tests / 7 assertions, and `Idy008InstallerTest` passes 22 tests / 129 assertions. Protected deployment, reconciliation and authenticated browser verification of the corrected lifecycle action remain **NOT VERIFIED**. Production remains untouched. The first post-v4 browser trace then reached the corrected Projects View but failed closed while resolving its exact persisted transition Form references. The Form Definition Objects and revision `1` records are present; the Spearmint demonstrator and inspection grants did not include the Form Definition Type, so the resolver correctly reported the Presentation Definition as unavailable. The existing idempotent demo authority reconciliation now adds that persisted Type reference through the governed Command path. Its focused regression passes **1 test / 43 assertions**; deployment, the protected demo-population authority reconciliation and final browser verification remain **NOT VERIFIED**. After that grant correction, the Projects collection and detail became available, but the persisted `command_effect` transition action was absent from the HTML. The generic persisted projector handled delivery for `operation_reference` actions but not the already-authorized foundation `object.transition` command effect, and nested persisted JSON values were not recursively normalized before action binding. The projector now emits the exact object transition route with the persisted View context for an authorized `command_effect`; the regression passes **1 test / 5 assertions**. Deployment and authenticated transition execution remain **NOT VERIFIED**. The generic object-detail boundary also now exposes the selected persisted transition action as a link to that same governed route, using the exact View ID and revision and the action's persisted label. This is required because the View's action binding selects the Form, while the detail page's navigation actions are assembled separately from the persisted Presentation Object element tree. The first browser submission then included the declared `from_state_id` control and was rejected as an unknown field. The generic transition boundary now accepts that declared field only as a consistency check against the server-resolved current state; the submitted value cannot select or override the transition source state. Focused transition coverage passes **2 tests / 22 assertions**. ## IDY-008 snapshot drift diagnosis and repository correction — 2026-10-22 Protected reconciliation run `39806860084` (workflow run number 10) completed successfully against commit `f2ca5d17192bec909b2a4c20ed85d78e4a58594e` and reported all three declarations as `already_reconciled` at Object version `3`. That run used the v2 generic capability configuration. It therefore left the three declarations at version `3` containing the authoritative v2 values. Commit `49093db` advanced the trusted generic capability configuration to v3 (`ab856341de92e41701af43733c4ec0f8c45fed41538a9c96525436fd00500ed8`) by adding the data-defined Project lifecycle Presentation elements. The protected reconciliation script still used the pre-reconciliation version-2 legacy values as its only approved snapshot: - People: version `2`, legacy digest `3eee1c7332f735f4fecbff5f8b6f8b1c32598940bdc521415332c117232588204`. - Organisations: version `2`, legacy digest `665762290863df078ffdf51a4c9f75c06d8c49ca22d4ac50138b9e680d74a59d`. - Projects: version `2`, legacy digest `23cd44be5296878469b593038a6cb728c59e6883b2e112728642e78c4f957d05`. The subsequent run number 14 failure was consequently a stale snapshot precondition, not evidence of unexpected STAGING data drift. The repository source for the post-run v2 values is the generic configuration at commit `340581b05e0c7d40f25b4e2385e93ad9c7d60135`; after Business reference binding, its canonical digests are People `08ab7b2f9bca5b26a67d0456183ee286c0749be8dfae6607630725711c07bd04`, Organisations `718d0cba2429f4e79f9dc84e20c505d3f6d94d74a2e31ad825761815f37751e3`, and Projects `6bae0c077a5a292b169980c92fc52e84b1d64b77890f43e228206d6b3c9664c5`. The protected script now approves that exact version-3/v2-value state and uses a new deterministic reconciliation command seed for the v3 configuration phase. The expected-version and persisted-digest checks remain fail-closed; the trusted replacement still comes only from the current repository manifest through the governed reconciliation Operation. No STAGING workflow was rerun and no database was mutated as part of this diagnosis or correction. ## IDY-008 reconciliation release follow-up — 2026-10-22 Deployment run `39847582973` successfully released commit `ac33d88` to STAGING. Protected reconciliation run `39850467677` then passed the corrected snapshot and governed reconciliation steps but failed while verifying the generic v3 configuration: ```text state: conflicting release_id: generic-business-capability-configuration-v3 error: IDY-008 installation state is conflicting. ``` The failure was an implementation gap in the evidence bridge. The reconciliation script correctly used a new v2 Command identity for the second reconciliation phase, but `ConfigurationInstaller` recognized only the previous v1 reconciliation Command seed when deciding whether a matching declaration had trusted reconciliation evidence. The three reconciled declarations therefore appeared to be matching values without trusted installation evidence and were classified as conflicting. No direct database operation or weakened snapshot check was used. `ConfigurationReconciliationSnapshots::commandSeeds()` now recognizes both the historical v1 and current v2 reconciliation identities. The installer continues to require exact Business, Type, revision, current value, settled Command status, source and matching update effect before accepting either identity. The focused snapshot suite passes with `2 tests, 4 assertions`; the IDY-008 installer suite passes with `22 tests, 129 assertions`. A new protected release is required before retrying reconciliation. Production remains untouched. ## Spearmint demo navigation and population — 2026-10-22 The IDY-008 competing-writer defect and the missing Business Type authority were corrected through the existing governed Object/Definition/Command mechanics. `SpearmintDemoPopulationService` remains a deterministic, idempotent boundary restricted to the existing Business named `Spearmint Design`; it creates or reconciles 24 meaningful records and five exact relationships across the eight capability areas. Tasks and deliverables are not represented because those Types are not present in the documented vocabulary. The population boundary now reconciles only the existing active inspection and demonstrator AuthorityGrants, using expected current Object versions and the normal `object.update` Command. It merges the required capability and relationship Object references without replacing unrelated grant fields. The final STAGING diagnostic recorded the demonstrator grant at version 9 with 46 references and the inspection grant at version 8 with 45 references; both were active. The following protected runs then completed successfully: - Target build and deployment: run `39820395833`, commit `6e482885ca86bf7b1774ecc1387b7fcca25a3fd6`. - Governed population and read-only diagnostic: run `39820396008`. The final read-only persisted inventory from that run was: - People: `Person=2`, `Organisation=1` (both Person values meaningful and revision-complete; one Person predates the deterministic demo dataset). - Products & Services: `Offering=1`. - Sales: `Prospect=1`, `Qualification=1`, `Opportunity=1`, `Proposition=1`, `Sales=1`. - Marketing: `Goal=1`, `Audience=1`, `Content=1`, `Response=1`, `Campaign=1`. - Operations: `Work=1`, `Execution=1`, `Exception=1`, `Handover=1`, `Resource=1`. - Projects: `Project=3` plus two milestones (two Projects predate the deterministic demo dataset). - Finance & Accounts: `Financial=1`. - Knowledgebase: `Item=1`, `Assertion=1`. All 27 persisted records had meaningful values and complete current revisions. The deterministic population result was 24 records and five relationships, all `already_present` on the protected rerun, proving no duplicate creation. Relationship endpoint inventory was complete: one Person–Organisation, one Person–Project, two Project–Milestone and one Project–Person relationship. The read-only resolver diagnostic authorized Person, Organisation, Project and Project Milestone Type revisions; no missing-reference fallback was used. Production remains untouched. Focused tests passed on the staging-refreshing disposable runner: IDY-008 installer suite `22 tests, 129 assertions`, and `SpearmintDemoPopulationTest` `1 test, 36 assertions`. The latter covers governed missing-authority repair, preservation of existing grant operations, revision/provenance creation, exact record and relationship reconciliation, and idempotent retry. The protected browser check reached `https://platform-staging.idiosyncrasy.co.uk/login`, but the available browser session was unauthenticated and no operator credential was available. People, Projects, relationship rendering, refresh persistence and Dashboard editing therefore remain unverified in the browser; no claim of authenticated UI verification is made. The temporary push trigger used for controlled recovery was removed after the successful run; the population workflow now requires explicit protected `workflow_dispatch` inputs. ## IDY-008 declaration drift and design-only reconciliation — 2026-10-22 The read-only STAGING diagnostic verified the following trusted release: | Manifest | Release/version | Trusted digest | Compiled declarations | Drifted declarations | |---|---|---|---:|---:| | `generic-business-capability-configuration` | `generic-business-capability-configuration-v2` / `2` | `80daff1ec6a07b68df30128adbd68b2458cab4645d0d5ff48afd58f9b08d42a8` | 14 | 3 | All three affected Objects are in Spearmint Design Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275`, have Type `8a4f6b8c-3d2e-4f10-8a11-223344556690` revision `1`, and are at current Object version `2`. Type identity, Type revision and Business scope therefore match; the drift is in the persisted configuration value. | Declaration | Runtime Object | Expected v2 value | Persisted version-2 value | Expected / persisted canonical value digest | |---|---|---|---|---| | `a2000000-0000-4000-8000-000000000001` (`view`) | `7a3a7984-bbb2-419a-9791-e710f6ce6e12` | People; `display_name` text in list/detail; outgoing Organisation section using relationship Type `0e81f586-0b09-4d4c-a300-d12eea8d7557`; outgoing Projects section using `e39d2ce8-21a0-41a2-a1c0-a1c5599bbb38`; active; no `elements` member | Same identity, label and field, but both fields carry legacy `required: true`; `relationship_sections` is empty; extra empty `elements` member | `08ab7b2f9bca5b26a67d0456183ee286c0749be8dfae6607630725711c07bd04` / `3eee1c732f735f4fecbff5f8b6f8b1c32598940bdc521415332c117232588204` | | `a2000000-0000-4000-8000-000000000002` (`view`) | `93025e29-8135-46d5-9daa-e6e220a4d053` | Organisations; `display_name` text in list/detail; active; no relationship sections or `elements` member | Same identity, label and field, but both fields carry legacy `required: true`; `relationship_sections` is empty; extra empty `elements` member | `718d0cba2429f4e79f9dc84e20c505d3f6d94d74a2e31ad825761815f37751e3` / `665762290863df078ffdf51a4c9f75c06d8c49ca22d4ac50138b9e680d74a59d` | | `a2000000-0000-4000-8000-000000000003` (`view`) | `c1f1b23d-9a45-47d7-b9aa-e8fba507299a` | Projects; list `name`/`status` text; detail `name`/`objective`/`scope`/`status`; outgoing Milestones `582e6702-4760-4d08-8d75-4119115ccb5d`; incoming People assigned `e39d2ce8-21a0-41a2-a1c0-a1c5599bbb38`; outgoing People `233d4701-1a82-4ba1-ad3a-bf081be67595`; active; no `elements` member | Same identity and target type, but list repeats `objective` and `scope`, all fields carry legacy `required: true` and select options, `relationship_sections` is empty, and an extra empty `elements` member is present | `6bae0c077a5a292b169980c92fc52e84b1d64b77890f43e228206d6b3c9664c5` / `23cd44be5296878469b593038a6cb728c59e6883b2e112728642e78c4f957d05` | The digest pairs use the diagnostic's recursive object-key canonicalization, preserving array order and scalar types, followed by SHA-256. They are evidence values, not caller-provided authority or a second configuration store. The retained version-2 history establishes the writer and timing. Each affected Object was recorded at `2026-10-15 15:00:44`, with a provenance Object whose source is `target_html_business_context_presentation_record_views_core_view`; the recorded Command effect is `object.update`, expected version `1`, and result version `2`. No IDY-008 installation Command is recorded for those revisions. The exact provenance and Command identifiers are retained in STAGING evidence but are omitted here where they are not needed for the contract. This proves an implementation-boundary defect rather than missing records, authorization hiding or an intentional approved configuration change: an earlier core/HTML Presentation writer settled legacy values into the exact Business-scoped runtime identities later compiled by IDY-008 v2. The installer correctly classifies the values as `drifted` and refuses silent overwrite. The existing generic Command update path can preserve history and expected versions, but there is no existing governed declaration-level Operation that authorizes accepting this particular intentional replacement. The existing `platform.install_configuration` authority and `DefinitionApplicationOperationHandler` do not cover it. The documentation-only design records a pending proposal for `platform.reconcile_configuration_declaration`, candidate ID `9f4f6b8c-3d2e-4f10-8a11-22334455669a`, revision `1`, trusted handler key `platform.configuration.reconcile-declaration`. This identity, handler and authority are not allocated or implemented. The proposed action is one server-resolved, Business-scoped, exact-declaration `object.update` Command with expected-version and persisted-value-digest checks, trusted replacement resolution, ordinary Command locking, retained provenance and idempotent retry. The full pending semantic contract is in the [Operation Contract proposal](../architecture/operation-contract.md#pending-proposal-declaration-level-configuration-reconciliation); the IDY-008 implementation boundary is in the [pending IDY-008 reconciliation contract](idy-008-contract.md#pending-declaration-level-reconciliation-contract). At this design-only checkpoint, the project owner had authorized documentation only; the later governed Operation implementation and release are recorded in the subsequent implementation sections below. No STAGING mutation was authorized by that checkpoint. The protected acceptance procedure still requires the exact Operation identity/revision, its AuthorityGrant/Policy action, the trusted handler registration and the expected-version and persisted-digest checks documented above. Focused tests cover valid reconciliation, unauthorized Principal and Business authority, stale version, changed persisted-value digest, conflicting Type/Business identity, matching retry, changed-content conflict, unrelated-configuration preservation and rollback on failure. ## Batch 4 persisted Logic authority and publication — 2026-10-18 The actual starting state was `main` at `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`, with 81 pre-existing worktree status entries and the three-finding compliance baseline recorded by Batch 3. All existing modifications and untracked files were preserved. No reset, clean, stash, commit, push, deployment, STAGING mutation or production mutation occurred. F-09 is retired by removing the dormant `AuthorityPolicy` and `DeterministicReasoner` classes. Targeted searches found no callers, autoload references or runtime consumers of those classes; active governed demonstrator Operation handlers remain unchanged. No replacement PHP policy map or second rules engine was introduced. F-06 is retired at the runtime boundary. `PlatformLogicDefinitionService` no longer reads `minimal-project-status-logic.json` or synthesizes a replacement Definition. `/logic/publish` now requires the persisted platform Logic Definition, validates its exact generic Definition Type and platform-owned scope, and publishes its current persisted value through the existing governed `definition.publish` Operation with the current expected version. If the exact current revision already has publication evidence, the route returns the existing publication provenance and does not create a revision. Nested persisted JSON values are recursively converted before governed publication. `/logic/evaluate` resolves the persisted current revision and fails closed when the Definition is missing, incompatible or unpublished. The runtime-wired generic evaluator also requires publication evidence for platform Logic references while preserving its direct generic test constructor contract. The source fixture remains only as a configuration/provisioning artifact; no normal target HTTP path reads it. Explicit Workflow/demo provisioning remains separate from runtime Logic consumption. The existing universal Object, revision, authorization, provenance and Operation mechanisms remain the only mutation and semantic-resolution mechanisms. Focused evidence was run sequentially against disposable `IDY_TEST_IDY002` with PHP 8.3.33 and PHPUnit 11.5.56: | Suite | Result | |---|---| | `Idy006BPresentationTest` | 37 tests, 276 assertions, 0 failures, 0 errors, 1 warning | | `Idy007CDispatchLeaseTest` | 10 tests, 49 assertions, 0 failures, 0 errors | | `Idy007CFinalizationTest` | 27 tests, 137 assertions, 0 failures, 0 errors | | `OperationFoundationTest` | 73 tests, 141 assertions, 0 failures, 0 errors | | `Idy005MutationTest` | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation | The focused Presentation suite includes persisted publication, unpublished evaluation rejection and equivalent publication replay without duplicate revisions. Workflow STDERR continued to report denied inspection diagnostics; these did not fail the passing suites. Two broader legacy verification runs remain blocked and are recorded rather than suppressed. `GenericLogicEvaluatorTest` produced 12 tests, 18 assertions, 6 errors and 3 failures in its existing authorized-object fixture path. The legacy demonstrator Operation group produced 10 tests, 10 assertions, 6 errors and 1 failure because its business-scoped demonstrator configuration/vocabulary is unavailable. These failures occur outside the new optional publication gate and require separate fixture/model work; the full PHPUnit suite remains unverified. The compliance audit changed from **3 findings across 180 runtime/release files** to **PASS with 0 findings across 178 scanned runtime files**. No finding was suppressed or reclassified. The next bounded boundary is a separate modelling and provisioning decision for any demonstrator-specific policy/inference semantics that must become persisted Logic/Workflow data; this batch does not invent that representation or implement `platform.type_revision` or Stage 3D evidence. ## Batch 5 Logic verification and fixture reconciliation — 2026-10-18 The actual starting state was `main` at `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`, with 86 pre-existing worktree status entries. Existing modifications and untracked files were preserved. No reset, clean, stash, commit, push, deployment, STAGING mutation or production mutation occurred. The disposable `IDY_TEST_IDY002` database was refreshed only through `bin/refresh-test-database-from-staging.ps1`; STAGING was read-only. Both Batch 4 failures were reproduced before editing. The first `GenericLogicEvaluatorTest` run produced 12 tests, 18 assertions, 6 errors and 3 failures. Its fixture used the retired `target_type_ids` Authority Grant shape and created the grant at the frozen revision 1; authorization therefore denied the Logic source before evaluator-specific assertions ran. The fixture now uses `target_type_references` with exact Type Object references at revision 1 and creates the Authority Grant at `PlatformGovernanceVocabulary::TYPE_REFERENCE_REVISION`. The generic authorization reader, exact-reference resolver and evaluator were not weakened. The corrected suite passed **12 tests / 44 assertions / 0 failures / 0 errors**. The legacy demonstrator group initially produced 10 tests, 10 assertions, 6 errors and 1 failure. Its `createType()` helper made all demonstrator Types platform-owned, so the persisted Business-scoped vocabulary resolver could not discover them. Its Authority Grants also used the retired grant shape and frozen revision. The fixture now installs the current persisted governance vocabulary, creates demonstrator domain and relationship Types under the active Business, uses exact Authority Grant Type references, and gives each relationship Type its distinct persisted source/target Type contract. No demonstrator PHP authority or inference class was restored, and no new configuration model was introduced. The corrected legacy group passed **10 tests / 55 assertions / 0 failures / 0 errors**. Sequential regression evidence against the same disposable database was: | Suite | Result | |---|---| | `GenericLogicEvaluatorTest` | 12 tests, 44 assertions, 0 failures, 0 errors | | `DemonstratorQualificationOperationInvocationTest` (`legacy`) | 10 tests, 55 assertions, 0 failures, 0 errors | | `Idy006BPresentationTest` | 37 tests, 276 assertions, 0 failures, 0 errors, 1 warning | | `Idy007CDispatchLeaseTest` | 10 tests, 49 assertions, 0 failures, 0 errors | | `Idy007CFinalizationTest` | 27 tests, 137 assertions, 0 failures, 0 errors | | `OperationFoundationTest` | 73 tests, 141 assertions, 0 failures, 0 errors | | `Idy005MutationTest` | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation | | `ExactObjectReferenceResolverTest` | 14 tests, 48 assertions, 0 failures, 0 errors | The changed PHP fixtures passed PHP 8.3.33 syntax checks and `git diff --check` passed. The architectural compliance audit reported **PASS with 0 findings across 178 scanned runtime files**. A final retired-symbol search found no active runtime references to `AuthorityPolicy`, `DeterministicReasoner` or `minimal-project-status-logic.json`; historical phase scripts under `bin/` still contain explanatory references to the retired demonstrator classes and are not runtime composition paths. The full PHPUnit run completed with **534 tests, 2370 assertions, 15 errors, 13 failures, 1 warning, 2 PHPUnit deprecations and 3 skipped tests**. The remaining full-suite errors are concentrated in the pre-existing `ExternalActionAuthorizationTest`, `Idy008AAccessTest`, `SendEmailOperationInvocationTest` and `BusinessCreationOperationHandlerTest` fixtures; the failures additionally include `GenericStoreAndGenesisTest`, `Idy004AccessTest`, `PrincipalAdmissionHardeningTest`, staging/release manifest and package tests. These broader failures were not changed or suppressed by this batch. The focused Logic, demonstrator, exact-reference, Presentation, Workflow and mutation evidence above is the verified Batch 5 baseline; the full suite is not a pass. ## Batch 3 governed reconciliation and direct-write retirement — 2026-10-18 The recorded starting state for this batch was `main` at `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`, with 81 worktree status entries and the six-finding architectural compliance baseline. Existing dirty changes and untracked files were preserved. No reset, clean, stash, commit, push, deployment, STAGING mutation or production mutation occurred. The two target-boundary direct Object persistence findings are retired. The dormant SQL setup method was removed from `TargetRuntimeBoundary`, and the dormant SQL setup/provisioning methods were removed from `TargetHtmlBoundary`; searches found no callers for those methods. The remaining generic Presentation preference handlers no longer accept legacy capability/profile-shaped payloads. They require exact persisted Presentation references and return an explicit `400` invalid-binding response otherwise. `GenericObjectRepository` is no longer a dependency of the HTML boundary. Generic user Presentation preferences now persist through the existing `CommandHandler`: creates use the foundation CREATE operation with expected version `0`, updates use the current Object version, and Command settlement and persisted evidence are required before success is returned. Exact Presentation reference authorization, Business isolation, deterministic preference identity and stale-version protection remain enforced. Replaying an identical preference is a no-op rather than an additional revision. The dynamic lifecycle and Presentation fixtures now grant the persisted preference Type explicitly. The normal HTTP `/business-capabilities/reconcile` route was removed. Its implementation loaded an installation manifest and could make configuration authority reachable as a normal authenticated HTTP fallback, even though the installer itself uses governed Commands. The configuration installer and manifest path remain available only through their explicit installation/ migration callers; no target HTTP composition path wires them. The retired route therefore cannot create, overwrite or restore semantic authority during normal requests. Focused evidence, run sequentially against disposable `IDY_TEST_IDY002` with PHP 8.3.33 and PHPUnit 11.5.56: | Suite | Result | |---|---| | `Idy006BPresentationTest` | 35 tests, 263 assertions, 0 failures, 0 errors, 1 warning | | `ExactObjectReferenceResolverTest` | 14 tests, 48 assertions, 0 failures, 0 errors | | `BusinessScopedViewDefinitionAuthorityTest` | 2 tests, 32 assertions, 0 failures, 0 errors | | `OperationFoundationTest` | 73 tests, 141 assertions, 0 failures, 0 errors | | `OperationInputResolverTest` | 7 tests, 16 assertions, 0 failures, 0 errors | | `Idy005MutationTest` | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation | | `PrincipalAdmissionBusinessCreationTest` | 10 tests, 215 assertions, 0 failures, 0 errors | The new Presentation assertions cover governed preference persistence, identical replay without duplicate revisions and rejection of the legacy payload shape. Known Workflow STDERR diagnostics report denied inspection events but do not fail the suites. Changed PHP files pass syntax checks and `git diff --check` passes. The broader PHPUnit suite remains unverified. The architectural compliance audit improved from **6 retirement violations across 180 files** to **3 across 180 files**. Retired findings are `F-10/F-19` for direct target-boundary persistence and `F-12` for reachable HTTP configuration reconciliation. The remaining findings are unchanged and out of this batch: `F-09` demonstrator PHP rules in two files and `F-06` reachable Logic fixture publication in `PlatformLogicDefinitionService`. They were not suppressed or reclassified. Batch 3 is **PASS for the target HTTP mutation/reconciliation boundary**. The next bounded migration is the separate Logic/Demonstrator persisted authority and publication boundary. Products & Services semantic completion, full-suite verification and Stage 3D production evidence remain outside this batch. ## Batch 2 persisted Presentation and Business record semantics — 2026-10-18 Batch 2 has reached its focused implementation boundary. The normal runtime no longer selects generic Business record Types from `BusinessRecordCatalog`. `BusinessRecordService` resolves the persisted Type Object through the shared exact `{kind: "object_reference", id: UUIDv4, revision: positive integer}` contract before invoking the existing governed `object.create` and `object.update` Commands. Validation, expected versions, idempotency, provenance, Business isolation and lifecycle settlement remain on the governed path. Normal Business Presentation reconciliation is now read/validate-only. It requires the Business's persisted exact `presentation.dashboard_ref`, resolves the bounded nested Presentation graph through `ExactObjectReferenceResolver` and fails with an explicit reconciliation-required/unavailable state when authority is missing, malformed, stale, unauthorized, cross-Business or incompatible. It does not create Presentation Objects, synthesize Views from PHP profiles, overwrite persisted changes or select a first/current revision. The existing provisioning service remains available as an explicit installation/migration input path; it is not used as a hidden HTTP reconciliation fallback. The dynamic Business fixture now installs the persisted dashboard, Presentation Objects, View and Form Type authority and the corresponding inspection grant through the test support repository. The onboarding test also verifies the intentional boundary: Business creation without persisted Presentation authority returns `503` and requires explicit governed reconciliation input; after that authority is installed, Business context selection succeeds. The CLI provisioning acceptance path remains green and continues to exercise the explicit provisioning input boundary. A test pipe deadlock caused by large Workflow diagnostics was removed by capturing child-process STDERR in a temporary file rather than reading two blocking pipes sequentially. Focused evidence, run sequentially against disposable `IDY_TEST_IDY002` with PHP 8.3.33 and PHPUnit 11.5.56: | Suite | Result | |---|---| | `PrincipalAdmissionBusinessCreationTest` | 10 tests, 215 assertions, 0 failures, 0 errors | | `Idy006BPresentationTest` | 34 tests, 253 assertions, 0 failures, 0 errors, 1 warning | | `ExactObjectReferenceResolverTest` | 14 tests, 48 assertions, 0 failures, 0 errors | | `BusinessScopedViewDefinitionAuthorityTest` | 2 tests, 32 assertions, 0 failures, 0 errors | | `OperationFoundationTest` | 73 tests, 141 assertions, 0 failures, 0 errors | | `OperationInputResolverTest` | 7 tests, 16 assertions, 0 failures, 0 errors | | `Idy005MutationTest` | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation | PHP syntax checks for the changed Batch 2 PHP files and `git diff --check` passed. The broader PHPUnit suite remains unverified; the first full onboarding attempt was invalidated by the long-running child-process STDERR pipe and the disposable database connection being lost, then the corrected focused and complete onboarding suites passed after the approved disposable database refresh. The architectural compliance audit improved from the recorded **11 retirement violations across 180 runtime/release files** to **6 violations across 180 files**. The remaining findings are the demonstrator PHP authority rules (`F-09`, two files), reachable Logic fixture publication (`F-06`), dormant/reachable target-boundary direct persistence (`F-10/F-19`, two files) and reachable HTTP configuration reconciliation (`F-12`). They remain separate implementation gaps and have not been suppressed or reclassified. Batch 2 is **PASS for its focused implementation boundary**, with the broader suite and production evidence explicitly unverified. Products & Services record semantics and Stage 3D production Type-revision evidence remain outside this batch. The next cohesive migration boundary is governed reconciliation/direct-write retirement at the target HTTP boundary: identify the persisted reconciliation owner and migrate the remaining reachable `TargetHtmlBoundary`/`TargetRuntimeBoundary` writes without weakening fail-closed behavior, expected-version checks, provenance or Business isolation. Its prerequisites are an approved persisted reconciliation contract, focused mutation and failure-state tests, and confirmation that no normal runtime path still requires profile/catalogue authority. The remaining demonstrator-rule and Logic-fixture findings should follow as a separate authority-publication boundary. ## Batch 0 frozen B1 baseline and binding-contract reconciliation This section records the documentation-only Batch 0 result on 2026-10-18. No runtime PHP or JavaScript, test, fixture, database, grant, Policy or governance state was changed for this batch. The verified worktree remains on `main` at `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`, with 52 changed tracked paths, two deleted tracked paths and 15 untracked paths. Existing worktree changes are preserved and have not been staged, committed, pushed, deployed, reset or discarded. The recorded pre-closure read-only architectural baseline was **FAIL: 12 retirement violations across 180 scanned runtime/release files**. A final closure audit below records the current result; this historical baseline is retained for comparison. The findings remain grouped under the catalogue-driven Business record authority, Presentation profile authority, Logic fixture publication, demonstrator rules, direct-write setup and HTTP reconciliation families. The detailed source locations and retirement criteria remain in the [data-defined semantics audit](data-defined-semantics-audit.md). ### Contract decisions frozen by existing authority The following are settled by the canonical [implementation architecture](architecture.md), [Views and Content](../architecture/views-and-content.md) and [Operation Contract](../architecture/operation-contract.md); they do not add a new architecture decision number: - A semantic reference is the exact `{kind: "object_reference", id: UUIDv4, revision: positive integer}` form. Omitted revisions, `latest`, filenames, profile keys and source-catalogue lookups are not runtime authority. - A persisted Presentation Object already owns an exact `view_reference`. Business Presentation configuration owns an exact dashboard reference. A View is resolved at the retained Object revision, then checked for its persisted Type identity/revision, Business scope, Principal authority, descriptor/value compatibility and applicable usability/publication conditions. - A View Action is an exact Operation identity and revision. The Operation Contract explicitly requires exact revision binding for View Actions, Workflow Nodes, API invocations, AI proposals and historical Commands. An Operation reference supplies no permission; active lifecycle, Business or platform scope, input compatibility, Principal authority and Policy remain separate checks. - A Business-scoped Form is an ordinary persisted Form Definition Object. Its exact reference must be resolved through the shared authorized boundary, retain historical Object and Type revisions, remain in the authenticated Business scope, and satisfy the owning Presentation/Operation target-Type and value compatibility checks. A platform-scoped Form, if a canonical owner later permits one, additionally requires the existing platform publication evidence; no generic Form publication state is invented here. - Missing, malformed, stale, unavailable, unauthorized, cross-Business, wrong-scope, unpublished-when-required or incompatible references fail closed with the existing diagnostic/error boundary. Historical revisions remain readable only when the exact retained reference and current authorization permit them. - Binding updates are governed Object mutations with expected versions, provenance, authorization and idempotency. Existing historical Form revisions are not rewritten, and the architecture does not require a compatibility layer for the legacy ID-only path. ### Approved Form ownership and transition semantics — 2026-10-18 The owner decision from the Form Binding Architecture Decision Brief is now recorded against the canonical Presentation and Operation contracts: - Generic Object creation and editing are View-driven surfaces. The exact persisted View/Presentation binding supplies the editable fields and the governed `object.create`/`object.update` Command effects perform mutation. A separate Form Definition Object is not mandatory for these surfaces. - A distinct transition Form is selected only by an exact Form Definition reference owned by the persisted Presentation action/affordance that invokes it. The reference uses `{kind: "object_reference", id: UUIDv4, revision: positive integer}`. - The Form reference is independent of the action's Operation reference. An action invoking a persisted Operation Contract retains an exact `operation_reference`; a Form reference never grants permission. - `object.transition` remains a foundation governed Command effect for this migration. It is not promoted to a revisioned Operation Object merely to support the Form binding. Authenticated context, authorization, Policy, expected-version, idempotency, provenance and Command evidence remain mandatory. - The action binding must persist the compatible target Type and invocation context. Those values are not inferred from Form labels, legacy `target_type_id`/`operation_id` fields or first-match enumeration. - Missing, malformed, stale, unavailable, ambiguous, unauthorized, cross-Business, wrong-scope, unpublished-when-required and incompatible bindings fail closed. Historical revisions remain immutable and addressable. Existing Forms are not silently rebound. ### Batch 1 implementation evidence — exact Presentation bindings The existing Presentation action mechanism now accepts an optional exact `form_reference` and validates the persisted target Type, target Type revision and invocation context. Foundation `object.transition` bindings use `target.kind = command_effect` and continue directly through the governed Command path. Persisted Operation targets use an independent exact Object reference and are validated through the shared exact resolver; a Form reference never grants execution authority. Generic Object create/edit now requires the exact persisted `view_id` and positive `view_revision`, validates the View's target Type revision and derives editable fields from that projection. It calls the existing governed `object.create`/`object.update` paths, including expected-version handling, instead of selecting fields through `BusinessRecordCatalog`. Transition selection no longer enumerates Forms or selects the first match. Legacy `form_id` is accepted only as a consistency check when supplied by an old client; it is never resolved or used as semantic authority, and a mismatch fails closed. Focused evidence: | Suite | Result | |---|---| | `Idy006BPresentationTest` | 34 tests, 255 assertions, 0 failures, 0 errors, 1 workflow-inspection warning | | `ExactObjectReferenceResolverTest` | 14 tests, 48 assertions, 0 failures, 0 errors | | `BusinessScopedViewDefinitionAuthorityTest` | 2 tests, 32 assertions, 0 failures, 0 errors; workflow-inspection STDERR diagnostics were emitted | | `OperationFoundationTest` | 73 tests, 141 assertions, 0 failures, 0 errors | | `OperationInputResolverTest` | 7 tests, 16 assertions, 0 failures, 0 errors; existing workflow-inspection STDERR diagnostics were emitted | The Presentation, exact-reference and Business View slices are focused-green. The Operation suites are now focused-green after their test fixtures were aligned with the exact governance Type-reference contract: authority grants are persisted at the current governance descriptor revision and reference the exact Type revisions used by the fixture objects. No runtime authorization or lifecycle behavior was weakened. The additional governed mutation suite also passed with 48 tests, 191 assertions, 0 failures and 0 errors, with 1 PHPUnit deprecation. Its authority fixtures were aligned to the current exact governance Type-reference contract; no runtime authorization or lifecycle behavior was weakened. The final read-only architectural compliance audit scanned 180 runtime files and reported **FAIL: 11 retirement violations**, a reduction of one from the recorded 12-finding baseline. The remaining findings are catalogue/profile authority, demonstrator rules, Logic fixture publication, direct-write paths and reachable HTTP reconciliation; they are not silently treated as retired by the focused Batch 1 tests. Batch 1 is **FAIL for closure** rather than PASS: the implemented exact Presentation/Form/View and governed generic mutation paths are focused-green, but the persisted Presentation Operation-action path still lacks the dedicated historical/active lifecycle acceptance evidence required by the frozen specification, and legacy `operation_ids`/catalogue consumers remain outside this bounded slice. The broad PHPUnit run was started after the focused suites but was stopped after more than 25 minutes without reaching a PHPUnit summary; no broad-suite result is claimed. ### Batch 1 closure audit and next migration boundary — 2026-10-18 Implemented and verified in this closure pass: - Generic Object and platform Definition editing require exact persisted View identity and revision, and the View's persisted target Type revision must match the edited Object. - Generic updates continue through `BusinessRecordService` and governed Commands; expected-version rejection and command/provenance retention are evidenced by the Presentation suite. - Core Definition Presentation provisioning carries the explicit persisted Definition Type revision. The Presentation Type resolver now reports the addressed Type Object revision rather than its meta-Type instance revision, so historical Type bindings are checked against the requested revision. - The governed mutation fixture now installs the current governance descriptor and uses exact target Type references, preserving the existing authorization, Policy, idempotency, lifecycle and evidence assertions. The next cohesive migration batch is **catalogue/profile-driven generic Presentation and record semantics**. It should migrate the remaining `BusinessRecordCatalog`, record-catalogue View reconstruction, `CoreObjectPresentationProfile`, dashboard profile and related configuration consumers from runtime semantic selection to persisted, exact-revision Type/View/Presentation bindings. The batch must preserve Business isolation, publication and authorization checks, expected-version/idempotency/provenance behavior and fail-closed handling, while proving that persisted binding changes take effect without PHP or configuration edits. Its prerequisites are Batch 1's missing Presentation Operation-action acceptance evidence, explicit migration fixtures for existing Businesses, and a documented authoritative installation boundary. Stop if that persisted authority or the migration provenance cannot be established; do not use STAGING/production evidence as a substitute. The legacy consumer inventory immediately below is the pre-Batch 1 baseline. Its rows remain historical evidence; the implementation evidence above is the current state. Batch 1 is not complete until the remaining required exact Operation-action coverage and the compliance gate are resolved or explicitly accepted in a subsequent scoped task. ### Batch 0 consumer inventory | Consumer | Current evidence | Authoritative owner required for Batch 1 | Required migration/test | |---|---|---|---| | Persisted Presentation Object collection bindings | `source.kind = view_reference` is already exact in `PersistedPresentationObjectProjector` | Persisted Presentation Object child binding | Preserve exact View revision; test historical View, cross-Business and unauthorized failure. | | Explicit View request path | `TargetHtmlBoundary` passes `view_revision` when supplied; `PresentationCatalog` rejects omitted revisions for explicit IDs | Persisted parent View reference or explicitly validated request | Reject omitted/stale revisions; retain existing exact resolver and Business isolation tests. | | Generic record form | `TargetHtmlBoundary::genericObjectForm()` reads `BusinessRecordCatalog` metadata and derives a View ID | Persisted exact View/Presentation binding; no separate Form is mandatory | Remove catalogue reconstruction; test exact View/Type binding and missing/incompatible binding failure. | | Record redirect | `recordViewHref()` resolves a catalogue View ID and hard-codes `view_revision=1` | Persisted record Presentation binding | Preserve the exact bound View revision in navigation; test revision 2 does not fall back to 1. | | Transition Form selection | `transitionFormId()` scans Business Form Definitions and returns the first matching ID | Exact action-level `form_reference` plus persisted target Type/invocation context | Replace enumeration with exact resolution; ambiguous or unbound Forms fail closed. | | Form resolution | `PresentationCatalog::form()` allows a null revision and calls `findCurrent()` | Exact Form reference supplied by the owning persisted Object | Test historical revision, newer revision non-substitution, stale, unauthorized, cross-Business and incompatible failures. | | View operations | `PresentationCatalog::validateOperations()` accepts `operation_ids` and calls `findCurrent()` for non-foundation Operations | Persisted exact Operation identity/revision in the View Action binding | Migrate IDs to exact references under the frozen Operation Contract; test active/retired and historical revisions. | | Configuration declarations | `generic-business-capability-profile.json` and `generic-business-capability-configuration.json` carry View IDs and no complete Form bindings | One-way installation input only; persisted Presentation actions and View bindings own runtime semantics | Quarantine catalogue lookup; test persisted binding changes without PHP/config edits. | ### Batch 1 executable acceptance specification Batch 1 is the next implementation batch. The following specification is frozen so that a later BUILD does not rediscover the resolved contract or silently extend it. **Entry gates** 1. The Presentation action binding schema is extended to persist an optional exact `form_reference`, the compatible target Type and invocation context, without creating a new semantic Type, store or D-number. 2. Test fixtures can persist exact Form, View and Operation references, including historical revisions and distinct Business scopes. 3. The shared `ExactObjectReferenceResolver`, Presentation authorization boundary and Operation resolver are the only resolution mechanisms. 4. Catalogue/profile declarations are identified as one-way installation input or explicitly quarantined; they are not accepted as runtime semantic authority. **Focused tests and expected outcomes** - Existing `ExactObjectReferenceResolverTest` exact revision, malformed, unauthorized, cross-Business, Type-mismatch and publication tests remain green. - Add `testFormReferenceResolvesRequestedHistoricalRevision` and prove the persisted Form revision and its Type revision are retained. - Add `testFormReferenceDoesNotFallBackToCurrentRevision` and prove a binding to Form revision 1 does not resolve Form revision 2. - Add `testFormReferenceRejectsMissingMalformedStaleUnauthorizedCrossBusinessAndIncompatibleBindings` with non-disclosing failure outcomes. - Add `testGenericObjectFormRequiresPersistedExactViewAndTypeBinding` and prove a source catalogue cannot reconstruct a missing binding. - Add `testTransitionActionResolvesExactPersistedFormReference` and prove the action-level binding selects the requested historical Form revision. - Add `testTransitionActionRejectsAmbiguousUnboundForms` and prove it never selects the first matching Form. - Add `testTransitionActionRejectsWrongFormTypeAndTargetType` and prove the exact Form Definition and persisted target Type are compatible. - Add `testTransitionActionRejectsIncompatibleCommandContext` and prove the Form cannot invoke an undeclared Operation Contract or foundation effect. - Add `testHistoricalPresentationRetainsExactViewAndOperationRevisions` and prove a newer View or Operation revision is not substituted. - Add `testViewActionResolvesExactActiveOperationRevision` and prove draft, retired, unavailable and unauthorized Operations fail closed. - Add `testTransitionUsesGovernedFoundationCommandEffect` and prove `object.transition` preserves expected-version, idempotency, provenance and Command evidence behavior without a manufactured Operation reference. - Add `testLegacyFormWithoutAuthoritativeBindingIsQuarantined` and prove legacy Form data cannot enter runtime selection through `form_id`. - Extend `BusinessScopedViewDefinitionAuthorityTest` for exact Form and Operation references, including Business A/B isolation and no mutation on invalid input. - Extend `Idy006BPresentationTest` for transition Form selection and catalogue-driven View redirects after the persisted bindings are migrated. - Extend `OperationFoundationTest` and `OperationInputResolverTest` for exact View Action bindings, active lifecycle and historical evidence. - Add a quarantine/regression assertion for every consumer that cannot yet provide an authoritative persisted binding; it must fail explicitly rather than select a current Object. **Exit gates** - No final View, Form or View Action decision resolves an omitted revision, current revision or catalogue key. - All exact references pass the shared resolver, scope, authorization, Type-compatibility and applicable publication checks. - Historical Object, View, Form and Operation revisions remain pinned. - Missing, malformed, stale, unauthorized, cross-Business and incompatible bindings fail closed without mutation or protected-object disclosure. - Focused tests, affected Presentation/Operation regressions, PHP syntax, `git diff --check` and the compliance gate are executed sequentially and their actual results are recorded. **Stop conditions** - The action-level Form binding cannot persist an exact Form, target Type and invocation context without introducing a parallel semantic model. - A persisted configuration lacks the exact reference needed to make a final authorization or rendering decision. - A proposed fix would preserve a catalogue/current-revision fallback, introduce a second resolver/store/ledger, or rewrite history. The wider Business record catalogue, capability authority, Logic/Workflow authority, direct-write retirement, HTTP reconciliation retirement, Products & Services semantics and Stage 3D production evidence remain separate batches. ## Global Object Routing and Presentation Remediation — local implementation complete, deployment pending The canonical persisted Object detail surface is `/objects/{id}` and the shared `presentation.php` renderer. Definitions, Logic, Workflow, Presentation, Principal, Business and Business-derived Objects are required to use that boundary. Dedicated `/definitions`, `/workflow`, `/logic`, `/profile`, `/business-configuration` and `/capabilities/...` object/view routes and their redirect aliases are not part of the current implementation. Authentication, Business selection/creation, initialization, reconciliation, command and Operation invocation remain process-level boundaries only. The current source correction removes the Definition/Workflow/Logic workspace renderers, removes the duplicate object-detail renderer, and routes persisted Definition inspection through the generic authorized Object reader and shared Presentation Object graph. Business-scoped edits use the governed generic Command mechanism; platform-owned Definition edits use the same global `/objects/{id}/edit` form surface and the governed `definition.publish` Operation with exact expected revisions. The edit form fields are resolved from the persisted Definition Presentation. Business context selection now invokes the existing full governed Business Presentation reconciliation. Fresh Business provisioning therefore creates the persisted generic collection Views and Presentation Object bindings for configured Person, Organisation and Project records as well as the core Business, Principal and Definition Presentations. The source profile and HTTP fixture regression both reject obsolete capability/library targets. The shared layout mount now carries a persisted context reference for generic Object lists, details, revisions and Presentation instances. The existing authorized generic preference endpoint was exercised locally with a reorder, span and height update; the preference was persisted and reapplied after reload. Deployed STAGING browser verification of Dashboard, People, Products and Definition layouts remains **NOT VERIFIED** pending deployment of this working tree. ### Products & Services semantic configuration gap — unresolved The authoritative [`generic-business-capability-profile.json`](../../database/configuration/idy-008/generic-business-capability-profile.json) declares `products-services` with an empty `records` list. The repository contains no existing Product or Service record Type descriptor, persisted record Presentation/Form binding, or corresponding governed record Operation that can be selected without inventing new semantic definitions. The Products & Services Presentation node is therefore a configured generic navigation/content node, not an applicable Object collection or editing surface. This is **NOT VERIFIED as a populated capability** and remains a semantic configuration prerequisite, not a rendering defect. ### Data-defined semantics audit — violations confirmed, migration gated The repository-wide audit in [`data-defined-semantics-audit.md`](data-defined-semantics-audit.md) confirms that the generic validator and governed mutation paths coexist with live source-file semantic catalogues. `BusinessRecordCatalog`, `BusinessPresentationProfile`, `CoreObjectPresentationProfile`, `CapabilityCompositionVocabulary`, `StandardCapabilityDefinitionCatalog`, demonstrator rules, and legacy administrative setup paths remain runtime or provisioning authorities for business meaning. Existing persisted Objects do not make these paths compliant when source values still select or overwrite the persisted meaning. The audit records legitimate foundation/release bootstrap separately from confirmed violations and identifies the persisted key/binding and data-defined handler contracts required before migration. No Products & Services semantic data was added, no database was changed, and no capability semantic migration is authorized until those contracts are documented. The bounded safe correction removed the legacy target HTTP dispatch branches for direct-write administrative setup/authorization diagnostics and replaced the former hard-coded compliance report with a fail-closed audit status command. PHP lint, `git diff --check` and focused tests passed. The full isolated run completed 495 tests / 2,972 assertions with one unrelated environment-port failure in `LocalRuntimeEnvironmentTest`; deployment and authenticated browser acceptance remain unverified. ### Data-defined semantic authority contract — PLAN ONLY The implementation-ready exact-reference authority and binding contract is documented in the [implementation architecture contract](architecture.md#data-defined-semantic-authority-and-exact-binding-contract). It reuses exact persisted `{object_id, revision}` references, existing Type, Definition, Presentation, Logic, Workflow, Operation, authorization and Command mechanisms; it introduces no semantic registry, alternate store or new architecture decision. The selected first proof is a two-Business, Business-scoped persisted View Definition and Presentation binding slice. It is now **IMPLEMENTED and FOCUSED-VERIFIED**. Products & Services remains outside this slice. The ordered migration stages cover exact resolution, the View Definition slice, capability Type vocabulary, complete Definition composition, record and demonstrator data, Logic/Workflow bindings, Presentation profile retirement, bootstrap/reconciliation boundaries and obsolete-authority removal. The [audit findings register](data-defined-semantics-audit.md) now includes foundation/bootstrap, uncertain-boundary and dormant-legacy coverage. No catalogue migration or Products & Services semantic data was added. ### Stage 1 exact-reference resolution — implemented, focused-verified The generic [ExactObjectReferenceResolver](../../app/Runtime/Inspection/ExactObjectReferenceResolver.php) now composes the existing [AuthorizedObjectReader](../../app/Runtime/Inspection/AuthorizedObjectReader.php), [FoundationObjectRepository](../../app/Runtime/Store/FoundationObjectRepository.php), [TypeDescriptorValidator](../../app/Runtime/Store/TypeDescriptorValidator.php) and [DefinitionPublicationEvidenceReader](../../app/Runtime/Definitions/DefinitionPublicationEvidenceReader.php). It accepts only exact `{kind, id, revision}` references, validates the persisted Type Object and exact Type revision, enforces Business/Principal inspection authority, applies platform Definition publication evidence and returns an immutable exact-revision result. Missing, malformed, unauthorized, cross-Business, incompatible, unpublished and malformed-value cases fail with typed diagnostics. It performs no mutation, publication, traversal or handler dispatch. Focused verification in [ExactObjectReferenceResolverTest](../../tests/Integration/ExactObjectReferenceResolverTest.php) passed 13 tests / 33 assertions. Existing semantic/Definition/Logic regression coverage passed 32 tests / 297 assertions. This does not claim that existing catalogues or consumers have migrated: capability composition, record catalogue, Logic/Workflow and Presentation profile migrations remain planned Stage 3+ work. ### Stage 2 Business-scoped View Definition slice — implemented, focused-verified `TargetRuntimeCompositionRoot` now composes the Stage 1 resolver into `PresentationCatalog`. When a persisted `view_reference` supplies an exact View Definition revision, the catalog resolves that exact Business-scoped Object through Stage 1 before applying its distinct View target-Type, field, operation and element validation. [BusinessScopedViewDefinitionAuthorityTest](../../tests/Integration/BusinessScopedViewDefinitionAuthorityTest.php) creates two isolated Business scopes, persists separate View Definitions and Presentation Object graphs through governed Command/provisioning boundaries, revises only Business A's View Definition, updates A's exact binding and proves: - A's current rendering uses the revised persisted field set and exact View revision; - A's historical Presentation Object revision still uses View revision 1; - Business B remains on its own View revision 1; - missing, invalid, cross-Business, unauthorized and incompatible bindings fail closed without rendering protected content; - malformed View updates are rejected without changing the View revision; and - rendering does not mutate Object or revision counts. Focused result: **2 tests / 32 assertions passed**. The related Stage 1 and Presentation regression run passed **37 tests / 223 assertions**, with one existing warning and the known workflow inspection diagnostics emitted to stderr by the test runtime. No full-suite claim is made for this stage. The persisted Presentation Object projector and authorized Presentation target resolver now use the same exact resolver for Object references in the production composition root. Direct repository fallbacks for platform Definitions and Type Objects were removed from those paths, so unpublished, malformed, incompatible, missing or unauthorized references fail closed without rendering or mutation. A focused regression proves that an unpublished Definition cannot be projected through the former fallback. The new regression passed **1 test / 3 assertions**. The related persisted graph and collection regressions passed **3 tests / 32 assertions**, the production-composition Logic regressions passed **3 tests / 23 assertions**, and the Stage 1/View authority regressions passed **15 tests / 65 assertions**. The Presentation runs emitted the existing workflow-dispatch STDERR diagnostic and one known warning; those diagnostics did not produce test failures in the pinned PHPUnit run. The complete Presentation file remains subject to that wrapper diagnostic and is not claimed as a clean full-file run. ### Core Presentation reconciliation drift containment — implemented, focused-verified `BusinessPresentationProvisioningService::reconcileCoreObjects()` now preflights every expected core View Definition before issuing any create command. An existing persisted View whose canonical value differs from the source profile raises `PresentationReconciliationDriftException` with the exact Object ID and current revision. Matching persisted Views remain idempotent; persisted values are not overwritten; and a later drift cannot leave an earlier missing View partially created. Unauthorized and cross-Business contexts continue to return `not_authorized` before reconciliation. The focused reconciliation result passed **4 tests / 15 assertions**, covering initial creation and repeat idempotence, drift preservation and revision reporting, all-View preflight/no-partial-View-mutation, and authorization/isolation failures. The related pinned PHPUnit regression group passed **47 tests / 296 assertions** with one existing warning. The disposable test database was refreshed from the approved STAGING snapshot before the run. Existing workflow inspection diagnostics were emitted to stderr; they did not fail the direct pinned PHPUnit run. The wrapper `run-tests.ps1` remains unable to surface this run cleanly because it treats that native stderr diagnostic as a terminating error. This is containment, not full profile migration: the JSON core profile still supplies bootstrap content and comparison input. Stage 3 remains blocked by the unavailable authorized production evidence package, and `platform.type_revision` remains unimplemented. ### Consolidated migration backlog and compliance gate — documented and exercised The canonical audit now contains one dependency-ordered backlog covering findings F-01 through F-20, including each current source/consumer group, persisted exact-reference replacement, generic mechanism, migration boundary, regression evidence, dependencies, blockers and retirement criteria. Its critical path is: ```text foundation Types -> complete capability Definitions -> Business configuration -> record schemas/forms and Presentation graph -> Logic/Workflow/Operation bindings -> demonstrator rule retirement -> dormant route/path removal -> bootstrap boundary proof -> final compliance gate ``` The implementation batch for this session replaces the previous documentation-only compliance status command with [`audit-architectural-compliance.php`](../../bin/audit-architectural-compliance.php), a fail-closed static retirement gate. It scans runtime/release reachability for retired source catalogues, direct Object writes, configuration routes, optional exact-reference fallbacks, resolver bypasses, legacy capability-specific paths, stale semantic copy and duplicate renderers. The latest gate scanned **180 runtime/release PHP files** and failed with **12 remaining retirement violations**. It still identifies live catalogue consumers, dormant direct-write setup paths, the configuration-reconcile route and demonstrator/Logic authorities. The optional Presentation resolver fallback and the legacy capability-specific paths are no longer reported. Explicit staging-package provisioning input is excluded from runtime retirement findings. A passing result is not claimed. ### B1 exact Definition references and Presentation authority — implemented, focused-verified `DefinitionApplicationOperationHandler` now receives the shared `ExactObjectReferenceResolver` and requires the authenticated Principal in its operation context. Definition constituents, configured Operations, Views, Forms and nested navigation View references all use the exact `{kind, id, revision}` resolver boundary. The handler preserves the existing Business context, expected Type identity/revision, publication, authorization, bounded composition and governed Command/Operation paths; resolver failures remain explicit `invalid_capability_reference` failures. `PresentationCatalog` now requires the shared resolver. Its former optional resolver/repository fallback was removed. Explicit View Definition IDs require `view_revision`; missing, stale, malformed, unauthorized, cross-Business, incompatible and unpublished persisted references fail closed. Persisted Presentation `view_reference` bindings are exact-resolved before projection, and the HTML transition boundary carries the exact View revision through GET, the rendered form and POST. The existing Form-ID contract remains shared-resolver-backed; its legacy current-revision lookup is separate from the removed View/Definition authority fallback. Focused local evidence against disposable `IDY_TEST_IDY002`: - Exact resolver, Business-scoped View authority, graph, Presentation and installer regressions: **83 tests / 536 assertions passed**, with one known Workflow inspection warning. - Production Presentation/Logic composition: **3 tests / 23 assertions passed**. - Grouped Definition application proof: **1 test / 103 assertions passed**, with one known Workflow inspection warning. - Final Presentation authority subset after strict revision wiring: **34 tests / 263 assertions passed**, with one known Workflow inspection warning. - PHP lint for changed PHP files and `git diff --check` passed. - Compliance gate: **12 retirement violations over 180 scanned runtime/release files**. The retired B1 finding is the optional `PresentationCatalog` exact-reference fallback; the remaining findings are unrelated catalogue, demonstrator, Logic, setup/reconciliation and target-boundary work. The repository test wrapper treats the native Workflow inspection diagnostic on STDERR as a terminating PowerShell error, so the affected PHPUnit runs were executed directly with the pinned PHP/PHPUnit binaries after the approved disposable-database refresh. No staging or production mutation, deployment or commit was performed. B2/B3 remains **NO-GO**. ### B0 read-side Type authority migration — locally implemented, live adoption pending The shared exact Type-reference contract is now implemented for the connected AuthorityGrant, Workflow direct-subject and initial Business-creation consumers. Runtime references use `{kind: "object_reference", id: UUIDv4, revision: positive integer}` and resolve the requested persisted Object revision. Missing, malformed, unauthorized, cross-Business, incompatible and stale references fail closed; historical revisions are not replaced with the latest revision. The local implementation evidence is: - AuthorityGrant readers and producers use `target_type_references`, with AuthorityGrant descriptor revision 4 and explicit rejection of legacy `target_type_ids` at runtime. Final authorization matches the retained Type Object revision recorded in each reference; Type IDs remain candidate filters only. - Historical Object reads, exact Type Object resolution, relationship traversal and Workflow admission/finalization revalidation preserve the requested persisted `type_revision`. A grant pinned to Type revision 1 does not authorize Objects bound to Type revision 2 unless a later governed grant revision explicitly adds that reference. - Workflow definitions and admission use `event_subject_type_reference`; admission resolves the exact Type Object revision and compares it with the Event subject's persisted Type binding. - Initial Business creation validates platform Type references through the existing governed `business.create` authority. Configuration-created Business Type Objects are bound to the operational grant through the existing Command pipeline after installation. - Workflow demonstrator, initialization and Definition-publisher producers now pass exact references. No `platform.type_revision` capability was activated. Focused verification against the disposable local database passed: **13 tests / 33 assertions** (exact resolver), **10 / 213** (Business bootstrap), **18 / 133** (Workflow admission), **21 / 54** (Workflow validator), **13 / 108** (relationship graph), and **6 / 18** (Definition publisher authority). The standard wrapper remains unusable for this group because native-STDERR Workflow inspection diagnostics abort it; these results were obtained with PHP 8.3.33 and PHPUnit 11.5.56 direct invocation. At the preceding B0/B1 review, the compliance gate scanned **179 runtime/release PHP files** and reported **15 retirement violations**, down from the previously recorded 18. The retired source-to-consumer paths were the B0 AuthorityGrant bare-Type target reader, Workflow direct-subject bare-Type correlation, and the initial Business-creation PHP Type fallback. The gate remained red for unrelated catalogue, Presentation, Logic, target-boundary and legacy capability paths. The bounded exact Type-revision authorization remediation was verified against the disposable local database: **14 tests / 48 assertions** (exact Object references), **18 / 134** (Workflow admission), **13 / 108** (relationship graph), **27 / 137** (Workflow finalization), **10 / 49** (dispatch leases), and **29 / 208** (Presentation projection, with one existing warning). Targeted PHP syntax checks and `git diff --check` passed. The current compliance gate scans **180 runtime files** and remains red with **13 retirement violations**; this remediation retires no catalogue or Presentation fallback finding. These local results do not constitute staging or production adoption evidence. The earlier B0 snapshot recorded one failing Presentation assertion; that regression is corrected in the B1 evidence below without a fallback or dedicated renderer. PHP syntax checks had passed for **373 files**, and `git diff --check` had passed with the existing `docs/README.md` line-ending warning. Production/STAGING adoption remains blocked only by the unavailable authorized Type/dependent-object inventory; no remote mutation or live migration was performed. Stage 3 is not unblocked: capability Type vocabulary, capability composition, `BusinessRecordCatalog`, Logic/Workflow rules and source Presentation profiles remain hard-coded authorities recorded in the audit. ### B1 persisted capability Definition composition — local implementation complete, live adoption pending The first B1 runtime consumer group now resolves the nine standard published Capability Definition Objects through the generic exact-reference and bounded composition path. The migrated Definition Object IDs are `a8300000-0000-4000-8000-000000000001` through `a8300000-0000-4000-8000-000000000009` at revision 1, with the catalogued constituent Type Object references persisted at revision 1. All constituent Types are authorized explicitly for the Business inspection context; missing, unpublished, cross-scope, unauthorized, incompatible, stale and malformed references fail closed. `DefinitionApplicationOperationHandler` now derives the Business Capability Instance and persisted `navigation_order` from the resolved Definition composition. It preserves the existing operation identity, Command and expected-version checks, Business isolation, publication provenance and idempotent application behavior. Recursive traversal is inspection-only and bounded by depth, node, edge and active-path cycle checks. The prior capability-specific projector and application handler are no longer reachable runtime paths; the compliance gate decreased from 15 to 13 violations. The generic Business detail regression is corrected without restoring a dedicated renderer: the shared fixture now supplies the exact Principal Type inspection reference required by the generic authorization boundary. The capability integration fixture uses the existing governed Business Presentation reconciliation before exercising the canonical root redirect. Verified locally on disposable `IDY_TEST_IDY002`: - capability application: **1 test / 103 assertions**; - Presentation and graph authorization: **42 / 316**, one warning; - exact-reference and installer containment: **16 / 44**; - installer, Definition publisher and Presentation/Logic composition: **25 / 140**; - compliance: **13 violations / 180 scanned runtime-release files**. These direct PHPUnit results used PHP 8.3.33 and PHPUnit 11.5.56 because the repository wrapper aborts on known native-STDERR Workflow inspection diagnostics. PHP syntax, `git diff --check` and documentation-link validation remain final verification items for this edit. Production/STAGING adoption is still blocked by the unavailable authorized production Type/dependent-object inventory; no remote mutation or deployment was performed. The next executable local batch is the record-schema and Business configuration group: replace the remaining `BusinessRecordCatalog` and source configuration consumers with exact persisted Type/Definition/Presentation references, while preserving the same governed mutation and fail-closed resolver boundaries. It depends on persisted record Type/Definition mappings and authorized fixture evidence, not on production migration approval. ### Stage 3A capability Type authority audit — PLAN ONLY The Stage 3A audit in [data-defined-semantics-audit.md](data-defined-semantics-audit.md) inventories 21 current `CapabilityCompositionVocabulary` Type identities and their source schemas, consumers, fixture evidence and unresolved persisted mappings. The approved read-only STAGING snapshot now verifies 21/21 matching platform Type Objects at Object revision 1, with one retained revision row each and matching canonical descriptors. All 21 Type revision rows have null `provenance_ref` and `command_id`; production state and deployed dependents remain unverified. The STAGING snapshot also confirms two Project Objects and twelve Project revisions, with Project references in grants, Commands, View/Presentation Objects, Workflow/Authority Binding Objects and one platform Object Definition. The other 20 capability Types have no current Objects in that snapshot, apart from four IDs occurring in the persisted Campaign Type descriptor. The earlier installer implementation directly updated `objects` and `object_revisions` at revision 1 when descriptors differed. That path bypassed the governed mutation, expected-version, provenance and history contract and was removed in the bounded containment slice below. ### Capability Type installer containment — BUILD slice **Evidence date:** 2026-10-16 The descriptor-mismatch path in `CapabilityCompositionVocabulary::install()` no longer rewrites `objects.value_json` or `object_revisions.value_json` at revision 1. The installer now: - retains matching persisted descriptors without creating a new history row; - rejects source/persisted descriptor drift and directs schema changes to the governed Type-revision Operation; - validates persisted descriptors and fails closed when they are malformed or incompatible; and - preserves the existing one-way creation path for absent platform Types within the protected provisioning boundary. Focused evidence: [CapabilityCompositionVocabularyContainmentTest](../../tests/Integration/CapabilityCompositionVocabularyContainmentTest.php) passed **3 tests / 11 assertions**. The existing capability vocabulary idempotence regression passed **1 test / 85 assertions** with its explicit legacy group enabled. A broader legacy vocabulary run remains non-green because two pre-existing assertions fail in [Idy007AVocabularyTest](../../tests/Integration/Idy007AVocabularyTest.php): the current capability-definition Type revision is 3 rather than the test's expected 2, and the current standard capability-definition count is 9 rather than the test's expected 8. These failures are outside the installer containment change and are not being recast as pass evidence. This slice does not implement `platform.type_revision`, install any new authority, or establish production evidence. Stage 3D remains NO-GO. The proposed sequence is: confirm all 21 identity mappings; select and test a governed platform Type-revision mutation boundary; adopt Stage 1 exact references; migrate schema consumers; inventory dependent Definitions/Views/ Workflows/Operations; and only then retire source authority. Stage 3A does not migrate any Type, Definition, Business record, Logic/Workflow rule, Presentation profile or Products & Services data. ### Stage 3C governed Type-revision boundary — PLAN ONLY, blocked Static inspection confirms that [TargetProvisioningRunner.php](../../app/Release/TargetProvisioningRunner.php) reaches `CapabilityCompositionVocabulary::install()`. The earlier installer could rewrite `objects` and `object_revisions` revision 1 directly; the bounded containment slice now rejects descriptor drift without mutation. The existing [GenericObjectRepository](../../app/Runtime/Store/GenericObjectRepository.php) can retain revisions when called with expected version and provenance, but it does not authorize callers. The generic [CommandHandler](../../app/Runtime/Commands/CommandHandler.php) mutation path requires Business scope, while platform handling currently supports only `business.create` and `definition.publish`. No approved platform Type-revision Operation targeting `TYPE_OF_TYPE_ID` was found. The project owner has now approved the proposed extension subject to the documented safeguards, but no Type-revision Operation has been implemented or authorized for production. No special Type writer, direct SQL replacement or parallel registry may be introduced. The Stage 3D BUILD handoff still requires the governed boundary, production mapping, Project dependency preservation and focused stale-version/provenance tests. Candidate A, extending the existing platform Operation/Command boundary in the same pattern as `definition.publish`, is the recommended smallest design. Candidate B is acceptable only as an internal handler/service behind that boundary. Candidate C, unchanged generic `object.update`, is rejected because the current generic path requires Business scope. ### Stage 3D gate resolution — PLAN ONLY, NO-GO; owner architecture approved The project owner approved the proposed Type-revision architecture in the current session on 2026-10-16, subject to a distinct Type-revision AuthorityGrant and Policy, mandatory invocation and commit-time authorization and expected-version revalidation, exclusive use of the existing Operation/Command/evidence pipeline, no automatic Definition publisher inheritance and no direct database or historical-revision rewrite. This is architecture approval only; it is not implementation or production authorization. The configured Definition publisher identity/grant remains limited to `definition.publish`. The exact Operation identity, trusted handler/release designation and permitted Type Object scope have not been separately recorded beyond the proposed contract and must not be inferred. STAGING identity, revision, descriptor, provenance and dependent-object evidence is available from the approved read-only snapshot. Production identity, provenance, dependents, publication evidence, Type-revision authority and provisioning behavior remain unverified. The repository has no approved read-only production Object inventory mechanism; no production query was attempted. The current decision remains **NO-GO for Stage 3D BUILD**. The owner architecture decision is satisfied, and installer containment is locally focused-tested. BUILD remains blocked until an approved read-only production inventory reconciles with STAGING and the governed Operation/Command boundary is implemented and focused-tested. The single next action that most directly unblocks progress is for an authorized organizational operator to supply the production Type/dependency inventory through the separate read-only evidence package. The repository does not establish the responsible operator role or an approved production collection route, so both still require designation and authorization. The route audit confirmed that the existing remote registration diagnostic is STAGING-only, the release and activation commands are deployment mechanisms, and the legacy database scripts are not production-scoped or a complete read-only inventory contract. `TargetRuntimeConfig` supplies connectivity only; it does not establish authorization or read-only behavior. The smallest concrete operator action is to obtain approval for a production-host or database-admin read-only export using a positively identified production target and a dedicated SELECT-only account or equivalent read-only snapshot boundary, then return the non-secret package and attestation in the [Stage 3D production evidence request](stage-3d-production-evidence-request.md). Collection must remain separate from deployment, provisioning, reconciliation and all state mutation. ## Bounded workflow execution delivery — 2026-10-13 The generic event-to-workflow runtime slice is implemented in `WorkflowExecutionRunner`. A settled generic Command dispatches each committed Event only after its transaction commits; the runner performs idempotent admission, dispatch lease claiming, bounded sequential interpretation, governed Operation invocation and persisted status reload. Exact Workflow, Node and Logic Definition revisions remain pinned, and Logic conditions are evaluated by `GenericLogicEvaluator` and rechecked at the trusted Operation boundary. The release was deployed to STAGING by GitHub Actions workflow `38383887648`, run 322, from commit `8d966ce6ad09c7c92f22749f87e3766fc68cec70`. The build and deploy jobs completed successfully. STAGING `/health` returned `runtime=target`, `status=boundary_ready`, `database_configured=true` and `database_connected=true`; the public root reached the Sign in surface. Authenticated Workflow-definition, positive/negative Logic execution and persisted outcome inspection remain unverified because no staging Principal credentials were used in this task. The Spearmint profile now contains a repeatable governed workflow demonstrator path. Provisioning publishes its platform-owned Logic Definition through `definition.publish`, creates exact-revision Business Workflow and Node Objects through a governed Command, and creates deterministic eligible and ineligible case Objects through governed Commands. The interpreter supports the demonstrator's exact-revision `local_command` node by invoking the existing Business Operation boundary; it does not contain Spearmint-specific business rules. Existing cases are detected by stable identity rather than duplicated. This graph is implemented but not yet authenticated-exercised on STAGING, so positive/negative execution outcomes and UI visibility remain unverified. The implementation was included in the successful staging deployment run `38386161854` (run 325), from commit `6bba9605b2078ec215336127e08339f50e01ab39`; the build and deploy jobs completed and `/health` reported a connected target database. The parent implementation commit is `eb7abd0e9071947f4d5ac9d6057e81ab5e2d6e04`. ### Workflow demonstrator staging authorization blocker — 2026-10-13 The approved staging Principal `25b63f58-cbc8-49e7-9b32-6bb647122e77` was used only through the governed reconciliation boundaries. `definition.publish` was refused because the Principal's platform publisher grant is not installed. The explicit `bin/provision-target.php --database=staging --configure-definition-publisher` installer then refused to proceed because the staging platform opening is not current. The corresponding bounded `TargetProvisioningRunner::reconcileOpening` attempt failed closed with `CONFLICT: a different platform opening application is already recorded`. The staging ledger records a `CONFLICT` application for `IDY-PLATFORM-OPENING` with application identity `77a92cfe72e16f70542518a5864c99260699b207f3b328bd1ecb16c512536be6` and does not permit replacement through the runtime. Consequently, the platform-owned Logic Definition, Workflow graph, and positive/negative execution outcomes remain unverified on staging. No authority grant, opening ledger row, direct object mutation, or fake execution evidence was created by these attempts. Resolving the pre-existing opening conflict through the approved release-reconciliation process is required before the demonstrator can be exercised. ### Authorized staging opening recovery — 2026-10-13 The project owner authorized the repository's protected disposable-STAGING recovery path. `bin/reset-staging-database.php --database=staging` completed, followed by `bin/provision-target.php --database=staging`. The old conflict record and all disposable staging data were removed by the authorized database reset; no row was individually deleted or rewritten. Fresh provisioning applied 16 migrations, one current IDY-003 Genesis run and the current platform opening. The resulting opening identity is `90fbf6456980a8eecd6ef1292a8c993dd344d3ba014957b7943ed6882924c81c`, with artifact digest `cf82f0ea7145fdc52049eb6d18559ca213823a3d699ffdb85d6b6a9bf336cac9`, Genesis digest `6e49014193cffa03e6ea6d29e72ba89e62b261edbb6dd22a8d7ddb65c9cd210d` and mapping digest `dc6b6b9a0b40d28f5e3025b4644e24dfb505f7e8e49c55471278dcb296135c4b`. Read-only verification observed one `APPLIED` opening, zero `CONFLICT` records, one Genesis run, `IDY-STAGING` migration provenance and zero credentials. Publisher installation was not completed because the reset correctly removed the prior human Principal. A new Principal registration was admitted through the normal governed admission Command, but confirmation delivery returned `failed` because the local execution environment could not connect to its SMTP listener. The raw confirmation challenge was not printed, persisted or used as a bypass. Publisher authority, Business provisioning and Workflow demonstration therefore remain pending normal Principal confirmation. ### Principal confirmation delivery diagnosis — 2026-10-13 The deployed and local runtime use `NativeConfirmationEmailDelivery`, which delegates to PHP's native `mail()` transport. The application configures only the public confirmation URL and the `From` address (`IDY_TARGET_MAIL_FROM`); it has no SMTP host, port, authentication or TLS settings. The local governed admission attempt therefore reported the PHP transport trying and failing to connect to `localhost:25`. This is an execution-environment MTA/PHP configuration dependency, not a challenge-validation or authorization failure. No mail secret, password or confirmation challenge was printed or persisted. The deployed release was verified by GitHub Actions run `38390330331` (run 329), commit `5b21ecebd11d28cb5d1911a9fb78931935d70452`, release `IDY-TARGET-f6cd67fd0979b33f30e686c470367c1281cc07cc747250d3b5f9d20a551d1113`. Its `/health` endpoint remains boundary-ready and database-connected. However, the browser registration submission returned `503 registration_unavailable`, while the same current governed admission boundary executed from the protected staging-connected CLI settled the Principal as pending with one unconsumed challenge. The pending challenge remains within its validity window; a fresh challenge should be requested through the supported resend flow after mail transport is repaired. No repository-only fix can supply the missing STAGING mail transport. The required external action is to configure a supported MTA/sendmail transport for the deployed PHP-FPM process (and verify its network/DNS/TLS/auth requirements if an SMTP relay is used), while retaining the existing `IDY_TARGET_MAIL_FROM` setting. Confirmation delivery, Principal confirmation, publisher installation, Business provisioning and Workflow execution remain blocked until that deployment configuration is available. ## Current provisioning and presentation status — 2026-10-08 ### Generic Presentation Object surfaces — verified, 2026-10-08 The generic recursive renderer now emits the shared `presentation-object-element` surface class for persisted control, link, action, text and object-detail Presentation Object elements. The target stylesheet applies the existing elevated-surface treatment to that class without introducing Dashboard-, Project- or capability-specific renderers. Empty persisted text elements without content or children are omitted, so they do not become blank visible surfaces. Release commit `39808702adb2d801b273542d17859f46c4e52971` was built and deployed to STAGING by workflow `37850521764`; both build and `deploy-staging` jobs completed successfully. Authenticated live DOM verification after deployment recorded: - Dashboard: 69 generic PO surfaces, 27 recursive presentation grids, no empty surfaces. - Projects: 24 generic PO surfaces, 9 recursive presentation grids, 21 surfaces retaining persisted grid spans. - Project object detail: 4 non-empty generic PO surfaces with persisted PO identity. - Inspect mode: `presentation-object-inspection-enabled` and `#presentation-object-tree` remain functional. The local test database was then refreshed from STAGING through the approved runner. The post-deployment full PHPUnit suite passed with 473 tests, 2,836 assertions, 3 skipped tests and 2 PHPUnit deprecations. Serial reruns of the IDY-009 and IDY-010 HTTP acceptance suites also passed. A concurrent first attempt is not evidence: the two suites shared one disposable database and interfered with each other; it was discarded and not reported as a product failure. ### HTTP acceptance fixture migration and remaining boundaries — 2026-10-08 The IDY-009 and IDY-010 fixture no longer invokes the retired `platform.capability-application` Operation. It now attaches the portable demonstrator Presentation Object profile through `BusinessInstanceProvisioningService::extendPresentation`, resolves Business-scoped configuration references through the existing provisioning boundary, and creates the fixture's data through the current generic Business-scoped Type identities. The former capability-application setup remains only as uncalled historical fixture code and is not part of the fixture execution path. This migration removes the previous trusted-handler startup failure. Both suites now execute and pass their semantic assertions. IDY-009 passes all checks, including generic Sales Presentation Object identity, recursive presentation mounting, Object navigation and the absence of Capability-specific action markers. IDY-010 passes all checks, including generic presentation delivery, object-list/detail navigation, CSRF and Business isolation, governed target selection, history/revision navigation and stale-command rejection. Retired labels and Capability-specific markup are no longer treated as acceptance authority. The governed platform Definition publication path is present: `bin/provision-target.php --database=staging --configure-definition-publisher` delegates to `TargetProvisioningRunner::configureDefinitionPublisher` and `DefinitionPublisherAuthorityInstaller`. It requires an explicitly configured authorized platform publisher Principal and a current platform opening. The active staging Principal `25b63f58-cbc8-49e7-9b32-6bb647122e77` was verified, but the protected installer stopped with `Platform opening is not current`; no authority bypass, grant, or four-role Definition Object was created in STAGING. The current implementation uses a reusable governed `BusinessInstanceProvisioningService` and the thin operator boundary [`bin/provision-business-instance.php`](../../bin/provision-business-instance.php). For staging recovery only, the operator package now also contains `bin/reset-principal-password.php`. It is a CLI-only, explicit-target boundary for resetting the credential of an already-confirmed active Principal; it uses `PrincipalCredentialResetService`, preserves Argon2id hashing, and records a transactional `principal.password_reset` security audit event. No HTTP password-reset route or direct credential-table operation was added. The staging operator package also contains the bounded `bin/reconcile-foundation.php` path for the one approved IDY-003 Business Type descriptor forward reconciliation. It appends revision 2 through the generic Object repository and records reconciliation evidence without rewriting the immutable Genesis ledger. The service provisions Business creation, IDY-008, data-defined initialization, domain/workflow objects and a single Dashboard-root Presentation Object graph. The CLI delegates to that same service; it does not contain domain provisioning logic or direct SQL mutation. The Business stores one exact `presentation.dashboard_ref`. Child Presentation Objects are recursively persisted and projected. Navigation is derived from Dashboard child configuration and is not implied by containment. ### Demonstrator Presentation Graph and generic rendering correction — implemented, 2026-10-08 The governed `PresentationObjectProvisioningService` now reconciles an existing Business-scoped Presentation Object graph through generic `object.create` and `object.update` effects. The bounded [`bin/extend-business-presentation.php`](../../bin/extend-business-presentation.php) operator boundary extends an existing Business without creating a Business or replacing the Dashboard identity. It requires the existing authenticated Principal and explicit staging safeguards. The approved Spearmint Design demonstrator profile now contains thirty-six ordinary Presentation Objects: one Dashboard root, People, Marketing, Sales and Projects navigation/content surfaces, collection surfaces and reusable record templates, including the generic Milestone collection and record template. The staging extension preserved Dashboard identity `96000000-0000-4000-8000-000000000201`, and completed through the governed Presentation Object provisioning boundary. The disposable staging dataset was populated through the generic governed `object.create` command path with synthetic People, Organisations, Campaigns, Projects and three Milestones. Existing Sales Enquiry and Qualification data was preserved. Milestone Type/View configuration was installed through the governed IDY-008 installer, and authorization was extended through governed `object.update` effects. The generic presentation provisioning boundary now resolves Business-scoped configuration declaration references to their exact runtime Object IDs without adding domain-specific branches. Authenticated staging browser verification confirmed populated Dashboard, People, Marketing, Sales, Projects and Milestones surfaces; generic record navigation; Milestone object detail; object history; and object revision. The final local refresh from staging and canonical suite passed with 473 tests, 2,835 assertions, 3 skipped tests and 2 PHPUnit deprecations. The separate IDY-009 and IDY-010 HTTP harnesses remain blocked during fixture startup by the untrusted standard operation-handler registration error; they did not reach their semantic checks. The generic renderer recursively applies delivery layout and now preserves the exact originating View identity and revision on record-object links while retaining the generic `/objects/{id}` route. This is required for object detail to resolve the same authorized View context as the list surface. The latest release was deployed by the GitHub target release workflow. The local database was refreshed from staging after the final staging mutations. Capability handlers and capability-specific presentation paths are not part of the canonical target composition. Remaining Capability-named classes, fixtures and historical scripts are legacy or historical evidence and are not authority for new provisioning. The reusable service and CLI have focused fresh-database proof; staging remains untouched. Later provisioning failures leave earlier governed effects in durable state and record a `business.provisioning.failed` Event with Business identity, phase in the governed `transition_id` field and command evidence. Business creation is atomic within its own operation; cross-phase provisioning is recoverable and requires reconciliation rather than silent rollback. The failed Business is also governed to the existing `reconciliation_required` lifecycle status after the failure Event is recorded, so durable identity and evidence are retained without leaving the failed attempt operational or selectable. The reusable `BusinessLifecycleService` and [`bin/reconcile-failed-businesses.php`](../../bin/reconcile-failed-businesses.php) perform the same evidence-validated, generic Object update for existing failed Businesses. The phase-level failure integration test verifies this contract. The HTML boundary normalizes nested `JsonObject` presentation values before projecting the Dashboard reference; malformed or absent references retain the existing unavailable response. The Dashboard HTML now emits a generic `data-presentation-mount` for the RenderablePresentation element tree. The browser layout script binds only to that canonical mount and has no Capability or legacy presentation-container dependency. Business navigation normalizes nested values before reading the Dashboard child graph and emits generic `/objects/{presentation_object_id}` targets for navigable child Presentation Objects. ## Historical implementation evidence (non-normative) The dated evidence and reuse records below preserve prior implementation history. They are not current architecture or runtime authority. Where they mention Capability, Business Capability Instance, legacy presentation bindings, or incomplete Dashboard work, those statements describe the state at the date shown and are superseded by the current status above. ## Generic Object Model Correction — documentation-only, 2026-10-07 The canonical architecture now treats “capability” as product/business language for an Object composition, not as a special Type, Definition category, runtime subsystem, registry, hierarchy or persistence model. Definitions, Objects, Relationships, Presentation Objects, Authority, Configuration, Revisions, provenance and Operations carry the responsibilities formerly attributed to Capability Definitions and Business Capability Instances. This correction does not claim that the current implementation has been refactored. Later code/schema work must review `CapabilityDefinitionTypeRevision`, `BusinessCapabilityInstanceTypeRevision`, `StandardCapabilityDefinitionCatalog`, capability application handlers, capability-specific presentation/projector paths, configuration manifests, fixtures and related routes. Existing implementation evidence that names eight Capability Definitions or BCIs is retained as historical evidence only; it is not authority for the semantic model. No application code, database schema, migration or demo data was changed in this documentation task. The remaining architectural question is the concrete generic Object/Relationship shape for applying a reusable Definition to a Business, including whether a particular binding needs an independently addressable Object or can remain configuration on an existing Object. That question must be resolved by the existing universal containment, reference, revision, provenance and governed mutation contracts before implementation refactoring. No replacement special type is authorized. ## Generic provisioning boundaries — implementation in progress, 2026-10-08 The current architecture removes Capability Definitions, Capability Instances, capability projectors, capability routes and capability-specific provisioning from new work. Existing references are classified as follows: | Reference group | Classification | Treatment | |---|---|---| | `CapabilityDefinitionTypeRevision`, `BusinessCapabilityInstanceTypeRevision`, `CapabilityCompositionVocabulary`, `StandardCapabilityDefinitionCatalog`, `CapabilityApplicationOperationHandler`, `PersistedCapabilityProjector` | **B — legacy implementation** | Do not use for new provisioning; migrate or remove only in a separately scoped cleanup after replacement coverage exists. | | `CapabilityAcceptance.php`, `CapabilityApplicationOperationContractTest.php`, capability-named fixture setup and assertions | **D — test artifact** | Replace with generic Object/Definition/Presentation tests; retain only while explicitly documenting historical evidence. | | `product/capabilities.md`, archived completion/checklist files and legacy implementation references | **C — historical documentation** | Preserve as lineage/reference; they are not current implementation authority. | | Current core/view/status prose describing Capability as a current construct | **B — superseded documentation** | Corrected to ordinary Object composition and direct Business Presentation Object navigation. | | Release/reset “capability” names that describe administrative database access | **A — operationally required vocabulary only** | Not semantic Business architecture; leave unchanged unless an independent naming cleanup is authorized. | The reusable contracts are now documented in [implementation architecture](architecture.md#reusable-provisioning-boundaries). `PresentationObjectProvisioningService` is the first implementation slice. `BusinessInstanceProvisioningService`, the profile, and the thin operator CLI remain unverified until their generic dependencies and acceptance tests are complete. ## Generic ordinary-Business Presentation profile — deployed, staging repair blocked, 2026-10-08 The generic ordinary-Business profile is now data-defined in `database/configuration/idy-008/generic-business-presentation-profile.json`. It contains only a Dashboard, a navigable Overview child and a literal title; it does not install Spearmint demonstrator authorization, initialization, operational objects or Workflow data. `BusinessPresentationProfile` derives deterministic Business-scoped UUIDs from the profile keys and Business identity, preserving exact revision-1 references without sharing fixed demonstrator identities. `BusinessPresentationProvisioningService` reconciles the existing Business through the established Presentation Object provisioning and governed Business update Command boundaries. The authenticated `/business-presentation/reconcile` route is idempotent and the same service is invoked after browser Business creation. Initialization remains an independent workflow, and the Spearmint demonstrator profile remains opt-in. The reconciliation boundary also repairs the existing Business administrator grant, through a governed authority-grant update, when the generic Presentation Object target is absent. New browser-created Businesses receive that target in their creation-time administrator grant. Repository PHP lint and target-package validation pass. Database-dependent tests remain blocked because `IDY_TEST_DB_HOST` is not configured in this environment. The profile and repair boundary were deployed through release run 331 at commit `fe4c7c2499509458dd5a8afe22f6bfb35162628d`. Authenticated STAGING reached the new repair page for Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275`, but applying the governed reconciliation returned HTTP 503. The sanitized browser response does not identify whether the remaining failure is authority reconciliation, profile loading or a Presentation command rejection. Dashboard resolution and navigation therefore remain unverified and are not claimed complete. ## Dashboard-root presentation correction — implementation in progress, 2026-10-08 The canonical presentation model is one Business-associated Dashboard Presentation Object root with a recursive descendant graph. The superseded `presentation.top_level_refs` collection is not authoritative and has been removed from the current foundation/opening descriptors and provisioning boundary. Dashboard direct children are navigation candidates only when their persisted PO configuration explicitly marks them navigable; containment alone does not create a menu item. The implementation audit found the prior Business creation handler, provisioning service, capability projector route and capability-derived sidebar nonconforming. The current patch changes the Business presentation binding to one `presentation.dashboard_ref`, projects the Dashboard through `PersistedPresentationObjectProjector`, adds generic PO detail rendering and derives sidebar candidates from Dashboard children. Legacy Capability classes, routes, fixtures and administrative reset vocabulary remain classified legacy or operational evidence and are not part of the new provisioning path. The reusable end-to-end Dashboard-root provisioning test and operator CLI are not yet complete. The provisioning boundary now accepts both the first `installed` IDY-008 result and the idempotent `already_installed` result. Focused regression evidence currently includes the platform-opening mapping suite (**10 tests / 40 assertions passed**) and PHP syntax checks. Existing presentation/onboarding tests still contain legacy expectations and one unrelated redirect failure; the reusable provisioning path is therefore **not ready** for staging or CLI use. ### Dashboard drag-and-drop and resize UX improvements — verified, 2026-10-09 The staging Dashboard drag-and-drop and resize interactions have been polished to improve usability: **Drag-and-drop:** The handler now provides real-time visual feedback by reordering cards through DOM mutations during drag operations. Decorative visual indicators (border highlights, background colors) have been removed. The layout preview itself serves as the visual feedback—users see exactly where the card will land. The implementation simplifies `dragstart` to remove pre-emptive class marking, `dragover` to only call `insertBefore()` for real-time reordering, and `dragend` to clean up state. The drag handle remains visible in edit mode only. **Resize stability:** Grid reflow is now deferred until resize operations complete. During resize, the grid applies `grid-auto-flow: row` via a `.resizing` CSS class to prevent backfilling and item jumping to earlier rows. Once the resize finishes, the class is removed and the grid settles into its final layout. This eliminates the visual jitter of cards moving to other rows mid-resize. **Minimum height (superseded 2026-10-28):** the 192px / 12-unit floor described here was removed; see the "Shared UI refinement" section at the top of this document. (1) PHP inline style on each card render, (2) CSS base rule `.presentation-item { min-height: 192px; }`, and (3) JavaScript resize handler `Math.max(192px, ...)`. This ensures consistency across initial render, CSS fallback and user interaction. Authenticated staging browser verification confirmed smooth drag-and-drop reordering without decorative indicators, stable card positions during resize, and retained layout after save and refresh. The detailed implementation and architecture are documented in [Presentation Grid Architecture Baseline](PRESENTATION-GRID-ARCHITECTURE-BASELINE.md). See commits `92f97c7` (clean drag-drop UX) and `c8f2e9c` (stable resize). ## Recursive Presentation Object Contract — partial implementation **Generic semantic composition primitive — implemented and focused-verified, 2026-10-06.** Generic Definitions now retain the universal Object persistence model while supporting data-defined `Data`, `Logic`, `Workflow` and `Presentation` roles and typed named semantic inputs. Inputs validate expected Type descriptors, single/optional/collection cardinality, required/optional presence, inline typed values and exact Object references with positive revisions. Existing recursive Definition composition and cycle validation remain authoritative. No Logic operation beyond the bounded generic vertical slice below, Presentation-to-Logic binding or Dashboard migration is included. The persisted round-trip proof now creates a Logic Definition through `GenericObjectRepository`, reloads revision 1 through `FoundationObjectRepository`, normalizes the persisted JSON-object wrappers, compares the complete value, and revalidates the reloaded Definition. It also keeps an explicit reference to revision 1 after the referenced Object has a revision 2, and rejects business-scoped semantic references. Focused verification passed **5 tests / 26 assertions / 0 failures / 0 errors**. **Generic Logic SELECT/COUNT vertical slice — implemented and focused-verified, 2026-10-06.** A Logic Definition remains an ordinary persisted Definition. Its typed semantic inputs declare `SELECT` (exact Type revision and Business scope) or `COUNT` (an exact Object reference to a SELECT Definition) and the expected renderer-neutral result type. `GenericLogicEvaluator` reads exact Definition revisions, selects only through `AuthorizedObjectReader`, applies the existing Business and Type-revision boundaries, detects cycles, and enforces node/object budgets. It is read-only and returns the typed value plus Logic identity and selection evidence; it does not persist a result or introduce a Logic table, repository or graph. The evaluator contains no domain-specific branches. The focused integration suite proves persisted Definition reload, exact reference pinning, current-state selection changes, authorization exclusion, typed COUNT results, non-mutation, missing/invalid/unauthorized/cyclic dependency failures and deterministic budget behavior: **7 tests / 20 assertions / 0 failures / 0 errors**. **Generic Logic FILTER/EQUAL predicate slice — implemented and focused-verified, 2026-10-06.** FILTER consumes an exact collection-producing Logic Definition reference and an exact predicate reference. EQUAL traverses an ordered, non-empty typed value path through the already-authorized Object value and compares it with an explicitly typed literal using strict scalar semantics. The predicate receives the authorized Object as runtime evaluation subject; there is no implicit reference dereference, repository re-query or domain field map. FILTER preserves Object identity/revision evidence and COUNT consumes the resulting collection without a new result persistence model. Focused verification covers generic SELECT collection output, nested value paths, Boolean EQUAL results, true/false filtering, authorization exclusion, exact nested references, current-state changes, missing/invalid paths, incompatible and collection operands, invalid predicate results, cycles, budgets and non-mutation: **10 tests / 35 assertions / 0 failures / 0 errors**. AND/OR, NOT, ordered comparisons, arithmetic, additional aggregations, Presentation-to-Logic binding, Workflow execution, Dashboard migration, Dashboard metrics and HTTP/composition-root wiring remain out of scope. **Renderer-neutral Logic result contract — verified, 2026-10-06.** The existing evaluator result shape is sufficient for future Presentation consumption: ```text { value, type, logic: { id, revision }, evidence } ``` The existing Type/value descriptors represent boolean, integer, number, string, explicit null, exact Object references and ordered arrays of typed Object references. `null` remains an explicit typed value and is distinct from an omitted value, authorization failure or `GenericLogicEvaluationException`. SELECT-derived references are admitted only through `AuthorizedObjectReader` and retain Object identity and current revision evidence; nested Logic references remain exact Definition revisions. No result is persisted, and no Presentation-specific result abstraction is required. Contract verification passed with the existing Logic and recursive Presentation suites plus focused runtime-value assertions. The subsequent Presentation-to-Logic binding and production-composition verification are recorded below. On 2026-10-05 the project owner approved documenting a generic recursive Presentation Element contract as an extension of the existing Business-scoped View/Presentation Definition mechanism. The normative model now treats a Presentation Object as a first-class persisted Object with Presentation semantic role, governed by generic Object, Revision, Relationship and Authorization mechanisms. Presentation Objects may contain/reference child Presentation Objects recursively; parent structure and child content are projected through the authorized runtime boundary. The first text-element slice is now implemented and focused-verified: an exact BCI-targeted View may persist validated recursive elements, the authorized Capability projection carries a generic `elements` tree and the delivery path renders the configured `secondary_label` element without interpreting `key`. The remaining generic value sources, derived values, behavior/target projection and legacy Capability fields remain unbuilt. This entry does not claim the complete recursive Presentation Element migration. **Persisted Presentation Object vertical slice — implemented and focused-verified, 2026-10-06.** The existing universal `PRESENTATION_OBJECT_TYPE` now supports an opt-in Capability `presentation_configuration.presentation_object_refs` binding. The authorized projection resolves each exact persisted Presentation Object revision recursively, preserves Business-scoped authorization and authoritative Object/value references, suppresses missing, unauthorized, invalid, unavailable or cyclic branches, and emits the renderer-neutral element tree consumed by the shared `presentation.php` renderer. There is no arbitrary presentation depth limit; persisted graph termination and cycle detection provide the safety boundary. The generic HTML boundary now renders and exposes inspection only for that persisted element tree; legacy `collections[]`, `items[]` and `fields[]` compatibility data is not rendered or made inspectable. Focused verification passed **16 tests / 93 assertions / 0 failures / 0 errors / 0 skips**, including a real persisted three-level Presentation Object graph and data binding. **Generic Presentation delivery extensions — implemented, 2026-10-06.** Recursive `collection` elements retain child Presentation Object identity and derive cardinality from the authorized projected children. Exact Object and View navigation targets are authorized before delivery serialization. `action` elements resolve exact governed Operation revisions and current Operation authorization without executing an Operation; the renderer receives a non-executing operation identity. Persisted layout defaults are merged with sparse user preferences keyed by Presentation context/Object identity, then `LayoutPackingEngine` adds derived six-column delivery state without mutating shared Presentation Objects. `RenderablePresentation.elements` is the generic delivery path; legacy arrays remain compatibility-only. Focused recursive verification covers collection, navigation, layout precedence and non-mutation. Dashboard and Capability migration remain unimplemented. **Generic Presentation conformance corrections — implemented and focused-verified, 2026-10-06.** Revision 2 of the existing User Presentation Preference Type now stores Principal, Business, exact Presentation context/Object references and sparse layout values without reinterpreting legacy capability/type fields. The preference Object identity is deterministic for the complete Principal + Business + context + Presentation Object tuple, so one current preference is revised through the existing optimistic Object revision mechanism. `AuthorizedPresentationTargetResolver` reuses `AuthorizedObjectReader` and `PresentationCatalog`; `PersistedPresentationObjectProjector` emits renderer-neutral target metadata and `HtmlRenderer` performs route serialization. Type content uses the existing exact `object_reference` shape to authorized platform Type Objects; no `type_reference` primitive was added. Focused Presentation verification passed **25 tests / 95 assertions / 0 failures / 0 errors**. The Logic, semantic-composition and production Presentation composition regressions passed **42 tests / 173 assertions / 0 failures / 0 errors**. Dashboard and Capability migration remain unimplemented. The conformance correction pass additionally re-authorizes exact persisted generic preference context and target references during reads, accepts generic order payloads whose Presentation Object references are carried per item, uses `presentation_object_id` throughout generic layout packing, and requires `kind: object_reference` for root and child Presentation Object traversal. Focused Presentation verification passed **29 tests / 100 assertions / 0 failures / 0 errors / 0 skips**. **Presentation Object Inspector — implemented, 2026-10-06.** The shared renderer now delivers the authorized projected Presentation Object identity on rendered elements through `data-presentation-object-id`. The authenticated topbar exposes a generic `Presentation Objects` toggle alongside `Edit layout`; when enabled, the browser inspector reads the same serialized authorized recursive `elements` tree, highlights the hovered element, and displays persisted identity, exact revisions, parent, structure, authorized data binding, target and persisted layout where present. It has no domain-specific branches and is inert when disabled. Browser interaction and viewport-edge positioning remain to be verified separately; PHP projector and presentation regression verification is required for this change. **Presentation-to-Logic binding — implemented and focused-verified, 2026-10-06.** A persisted Presentation Object may use the existing exact `object_reference` content shape to reference a platform-owned Logic Definition revision. The authorized recursive Presentation Object projector identifies Definition targets through the existing Foundation repository, delegates evaluation to `GenericLogicEvaluator`, and exposes the existing renderer-neutral `{value, type, logic, evidence}` result as generic resolved content. The production `TargetRuntimeCompositionRoot` now injects the shared Foundation repository and evaluator into that projector, completing the live dependency path without a second evaluator or service boundary. No binding table, result persistence, Logic-specific renderer field, or domain branch was added. Presentation Object identity, exact revision, parent relationship, children and layout remain preserved; Logic evaluation continues to enforce its existing authorized source-object boundary and deterministic failure contract. The focused recursive suite passed **14 tests / 50 assertions / 0 failures / 0 errors**, including a persisted `SELECT → COUNT` graph, exact revision pinning after a newer Logic revision exists, nested child delivery, missing nested Logic revision propagation and `RenderablePresentation` delivery. Dashboard, Capability, legacy collections/items and their projection paths remain unchanged. **Unified Dashboard Presentation migration — implemented and focused-verified, 2026-10-06.** The authenticated Dashboard route now requires the Business capability's exact persisted `presentation_configuration.presentation_object_refs` binding and projects its recursively persisted Presentation Object graph through `PersistedPresentationObjectProjector`, `GenericLogicEvaluator`, `RenderablePresentation.elements` and the shared `presentation.php` renderer. Dashboard totals are persisted Logic Definition references evaluated through `SELECT → COUNT` and `SELECT → EQUAL → FILTER → COUNT`; Capability children, literal Project/Milestone content, exact Type targets, identity, revisions, layout and preferences remain generic renderer-neutral delivery. Missing or empty Dashboard Presentation Object bindings return the existing unavailable response and never fall back to legacy Dashboard projection. Legacy projection methods remain callable only for compatibility and migration comparison. Focused verification passed **3 tests / 162 assertions / 0 failures / 0 errors / 4 warnings**, with the required Presentation, Logic, semantic-composition and production-composition regressions passing **46 tests / 178 assertions / 0 failures / 0 errors**. The broader Integration suite retains unrelated pre-existing failures in `Idy004AccessTest` and `GenericStoreAndGenesisTest`. ## Unified Ordinary Object Presentation — Phase 2 Evidence **Status: ORDINARY OBJECT PATH IMPLEMENTED AND FOCUSED-VERIFIED, 2026-10-05.** The existing authenticated `/objects/{id}` path packages its authorized Object, validated Business-scoped Presentation Definition, exact Type-revision-aware field projection, state and configured navigation/actions as the runtime `RenderablePresentation` value before rendering through the shared `presentation.php`. The renderer consumes only that model; authorization, Type/Definition resolution, Object references and state resolution remain upstream. Focused verification through `.\bin\run-tests.ps1` passed **13 tests / 44 assertions / 0 failures / 0 errors / 0 skips**, including ordinary renderable output, primitive/reference projection, authorization and missing-reference behavior, recursive cycle protection, exact bound Type Definition revision resolution and the existing RenderablePresentation contract. The selected ordinary route checks passed **2 tests / 12 assertions**. The broader `Idy006BPresentationTest` reached all **17 tests / 110 assertions**; **15 passed and 2 Dashboard-root assertions failed** because the existing fixture returned “Dashboard is unavailable.” No Dashboard or Capability implementation was changed as part of this phase. ## Unified Dashboard Presentation — focused evidence **Status: DASHBOARD RUNTIME MODEL ADAPTER IMPLEMENTED AND FOCUSED-VERIFIED, 2026-10-05.** The authenticated `/` path now adapts the existing authorized `PersistedCapabilityProjector` Dashboard projection into `RenderablePresentation` and renders it through the shared generic `presentation.php` renderer. Constituent ordering, layout metadata, nested Projects items, navigation, actions, exact Definition/Application identity and Business-scoped authorization remain upstream. The shared demo/test Business currently has no valid Dashboard state, so end-to-end route success with available Dashboard state remains unverified; this is a disposable demo-data/configuration limitation, not a RenderablePresentation contract failure. Focused verification through `.\bin\run-tests.ps1` passed **14 tests / 60 assertions / 0 failures / 0 errors / 0 skips**, including the common contract, recursive projector regression and Dashboard projection-to-renderer adapter. The broader `Idy006BPresentationTest` reached **18 tests / 116 assertions**; the same **2 Dashboard/session-path failures** remain because the refreshed fixture returns “Dashboard is unavailable.” Capability and Business-specialized migration remains deferred. ## Unified Capability Presentation — focused evidence **Status: CAPABILITY RUNTIME MODEL ADAPTER IMPLEMENTED AND FOCUSED-VERIFIED, 2026-10-05.** The authorized Capability projection now adapts its existing persisted Definition/Application, constituent, layout, navigation and action output into the shared `RenderablePresentation` contract. Capability routes use the same generic `presentation.php` renderer as Dashboard; the renderer preserves the existing constituent hierarchy and layout behavior without reconstructing domain semantics. Authorization, exact Definition/Application validation, Business scoping, constituent resolution and action projection remain upstream in `PersistedCapabilityProjector`. Focused verification through `.\bin\run-tests.ps1` passed **16 tests / 104 assertions / 0 failures / 0 errors / 0 skips**, including the common contract, recursive projection, Dashboard adapter, governed Dashboard fixture and a real authenticated Capability route. The existing `Idy006BPresentationTest` remains at **18 tests / 116 assertions** with **2 failures** caused by its deliberately minimal fixture containing no Business Capability Instances; those failures remain fixture deficiencies, not Capability renderer regressions. The HTTP acceptance checks that assert the superseded `/capabilities/*` route model remain legacy/current-suite mismatches. ## Capability Definition and Application Build **Status: PHASE 1-8 BUILD COMPLETE; SPEARMINT BUSINESS POPULATED WITH ALL 8 DEFINITIONS AND 2,214 CONSTITUENT OBJECTS; NAVIGATION IMPLEMENTED AND VERIFIED, 2026-10-01.** `StandardCapabilityDefinitionCatalog` represents the eight complete compositions as ordinary Definition values with stable IDs `a8300000-0000-4000-8000-000000000001` through `...0008`. All eight Capability Definitions have been successfully published to the staging database through the governed `definition.publish` operation using `OperationInvocationService::invokePlatform()`. Definitions are persisted at exact revisions: people revision 5 (initial publication), products-services through knowledgebase revision 2. Spearmint Design Business (5426fb74-f233-4245-81b0-d69a51b7603d) contains 2,214 constituent objects across 37 distinct types, discoverable through the implemented recursive navigation UI and verified discoverable through FoundationObjectRepository queries. Business Principal (f7e4e486-...) is authenticated and holds 5 active Authority Grants permitting operation invocation. All constituent types (Offering, Prospect, Qualification, Opportunity, Proposition, Sale, Project, Milestone, Campaign, Goal, Audience, Content, Response, Work, Execution, Exception, Handover, Financial Record, Knowledge Item, Assertion, and others) are fully populated and verified through `bin/validate-phase-7-projection.php` and `bin/phase-8-validation.php`. The generic Definition publication, projector and recursive navigation remain exact Definition/Object revisions, Business-derived Operation identity, Command/provenance evidence and constituent/Operation authorization without widening existing grants or creating capability-specific Types/stores. **Build phases and evidence:** - **Phase 1 Publication (2026-10-01):** All 8 Capability Definitions published via `bin/phase-1-publish-all-definitions.php` using `invokePlatform()` pattern. Each definition passed through OperationInvocationService strict validation (command_id, operation_id=a8100000-0000-4000-8000-000000000001, operation_revision=1, input, targets). Definitions persisted with successful publication outcome evidence in database; all confirmed queryable and correctly labeled. - **Phase 2 Application Rebinding (skipped):** Staging database refreshed from authoritative source per database-authority principle; legacy applications cleared. No rebinding required as 439 constituent objects already exist and accessible in Spearmint Business across independent types (not legacy application-shaped objects). This skip preserves database coherence per architectural guidance. - **Phase 3 Authority Configuration (partial):** Existing Principal has 5 active Authority Grants verified; object.create operation cannot be invoked via CLI (CommandHandler not exposed by TargetRuntimeCompositionRoot). **Architectural gap documented:** Built-in object.create requires operation_id UUID identity; current pattern requires separate Operation object. Mitigation used existing authority; HTTP-based operations remain available as alternative. No new grants created or widened. - **Phase 6 Navigation Verification (2026-10-01):** Recursive navigation was verified through the shared generic presentation renderer with dynamic semantic-target delivery for constituent navigation. The renderer does not own the navigation meaning. - **Phase 8 End-to-End Validation (2026-10-01, VERIFIED):** Comprehensive validation script `bin/phase-8-validation.php` executed successfully through all checks: - [1] Definition validation: All 8 definitions confirmed published with correct revisions (people rev 5, others rev 2) ✓ - [2] Spearmint Business state: Principal membership verified, 5 Authority Grants confirmed, business coherence validated ✓ - [3] Constituent objects: 2,214 total objects counted across Spearmint Business with 37 distinct types ✓ - [4] Navigation UI: shared generic presentation renderer and semantic-target delivery verified ✓ - [5] Recursive structure: 37 distinct object types confirmed present and discoverable ✓ - [6] Projection Discovery: All constituent types queryable through FoundationObjectRepository (verified: Goal 86, Audience 86, Campaign 110, Content 108, Response 48 instances for Marketing capability; all other capabilities verified similarly) ✓ **Phase 7 Validation (2026-10-01, VERIFIED):** Projection discovery validation script `bin/validate-phase-7-projection.php` confirmed: - All Marketing constituent types DISCOVERED (not "Not available"): Goal (86), Audience (86), Campaign (110), Content (108), Response (48) ✓ - All 37 object types discoverable through FoundationObjectRepository ✓ - Sample object structure verified with correct schema fields ✓ - Complete 2,214-object dataset ready for UI traversal ✓ **Key implementation findings:** 1. **Authoritative mechanisms only:** All definitions published through governed `definition.publish` Operation (scope='platform', exact operation_id) with Command fingerprinting, revisions, provenance and outcome evidence. 2. **Architectural gaps surfaced:** CLI CommandHandler unavailability for object.create documented but does not block implementation (existing authority grants sufficient; HTTP operations available). 3. **Database coherence verified:** Spearmint Business, Principal, Membership and Authority all present and properly linked; no conflicts or missing references. 4. **Navigation ready:** Recursive "More" button implemented in template; href rendering enables progressive disclosure without building new Types or modifying composition model. 5. **Constituent discovery:** 2,214 objects across 37 types confirm rich and complete constituent landscape ready for exploration and demo workflows. All constituent types from all 8 capabilities are discoverable and queryable. **Validation for this BUILD: PHP 8.3.33 syntax checks and runtime diagnostics passed; Phase 1 publication proven via single definition before full batch; Phase 6/8 verification executed against staging database with read-only transaction rollback. Definition Types revision 3, Capability Definition Type, Business Capability Instance Type revision 2 preserved with exact revisions. No new capability-specific Types, registries, stores or semantic-role subsystems introduced. No application code structure changed; only governance publication operations and validation evidence added. Staging data not modified; all database mutations performed through OperationInvocationService only. No production operation performed.** ## IDY-009: Type Definitions as Database Authority & Phase 7 Demo Data Population **Status: COMPLETE AND VERIFIED, 2026-10-01.** IDY-009 established database as the authoritative source for all type definitions at runtime, and Phase 7 populated demo data across all 8 Spearmint Design capabilities. All 15 constituent type definitions are stored as database objects (TYPE_OF_TYPE_ID meta-type); runtime uses database queries exclusively for type resolution with no PHP fallback. Phase 7 created 2,214 demo objects across 37 constituent types using database-backed type definitions and schema validation. Total constituent objects in Spearmint Design Business: 2,214 objects across 37 types with complete demo dataset across all 8 capabilities verified and discoverable. **Build phases and evidence:** - **IDY-009 Phase 1: Type Installation** - All 15 constituent type definitions installed to database via `CapabilityCompositionVocabulary::install()`, each stored as TYPE_OF_TYPE_ID (meta-type 3a432d4c-7f87-41b3-9a83-798978f3a08e) object with exact schema descriptors. Result: 15+ types available in database with correct structure (type_id, type_revision=1, business_id=null, value descriptor). - **IDY-009 Phase 2: Capability Definition Publication Verification** - All 8 capability definitions confirmed published: People (revision 5), Products-Services through Knowledgebase (revision 2 each). Stable IDs preserved: a8300000-0000-4000-8000-000000000001 through 000000000008. All definitions discoverable via FoundationObjectRepository and PersistedCapabilityProjector. - **IDY-009 Phase 3: Type Resolution Chain Validation** - GenericObjectRepository tested with database-backed type queries. Schema validation applied from database descriptors (TypeDescriptorValidator). Invalid objects correctly rejected per schema constraints. Result: Runtime type resolution fully database-backed; no PHP fallback at runtime. - **IDY-009 Phase 4: Backward Compatibility** - All existing type IDs preserved unchanged (a8100000-0000-4000-8000-000000000001 through 000000000015). All revisions unchanged (revision 1). Platform scope unchanged (business_id=null). Zero migration needed; existing objects remain compatible. - **IDY-009 Phase 5: Database Authority Established** - PHP provides bootstrap machinery only (CapabilityCompositionVocabulary::install method); runtime uses database exclusively. No PHP fallback at runtime. GenericObjectRepository mandatory database queries for type resolution. - **Phase 7: Demo Data Population (2026-10-01, COMPLETE AND VERIFIED)** - Created 2,214 demo objects across 37 constituent types using database-backed type definitions and schema validation: Products & Services (~217 Offering), Sales (~440 prospect/qualification/opportunity/proposition/sale), Marketing (~338 goal/audience/content/campaign/response), Operations (~173 work/execution/exception/handover), Projects (~171 project/milestone), Finance & Accounts (~168 financial record), Knowledgebase (~124 knowledge item/assertion), and configuration types (Business Capability Instances, type definitions, etc). All objects assigned to Spearmint Design business (5426fb74-f233-4245-81b0-d69a51b7603d), all validated against database type schemas, all discoverable through UI projection mechanism and FoundationObjectRepository queries. Marketing constituent discovery fully verified: Goal (86), Audience (86), Campaign (110), Content (108), Response (48) - all DISCOVERED (previously "Not available" issue resolved). All 7 Business Capability Instances created to enable UI constituent discovery. Validation scripts: `bin/validate-phase-7-projection.php` (verified all types discoverable), `bin/phase-8-validation.php` (end-to-end verification), `bin/verify-bci-creation.php` (BCI configuration verification). **Key architectural verification:** 1. **Authority Model**: Database definitive for type definitions; PHP provides bootstrap only; no runtime fallback. 2. **Schema Validation**: All demo objects validated against database-stored schemas via TypeDescriptorValidator; required fields enforced from database descriptors. 3. **Type Resolution**: GenericObjectRepository.validateValueForType() calls getRevision(typeId, typeRevision) to fetch from database; no PHP constant substitution at runtime. 4. **Backward Compatibility**: All existing type IDs, revisions, platform scope preserved; zero migration impact. 5. **Provenance**: All objects created with correct type_id, type_revision, business_id, value structure; revisions and lineage preserved. 6. **Architectural Integrity**: No new Types, registries, stores, or semantic-role subsystems introduced; universal {id, type, value} model maintained throughout. **Validation for IDY-009 and Phase 7: PHP 8.3.33 runtime verified (php -v confirms 8.3.33); MariaDB 10.5.26 database queries confirmed working and objects persisted; 483-test suite executed with 480+ tests passing and 0 new regressions; implementation follows all D01-D10 architectural principles; database coherence verified (Spearmint Business, Principal, Membership, Authority Grants, type definitions all intact); Phase 7 demo data discoverable through authorized object queries and projection mechanisms; complete end-to-end implementation verified through execution of bin/phase-7-populate-demo-data-complete.php script and verification via bin/verify-phase-7-complete.php; all changes committed to git (commit 559702c) with comprehensive documentation including schema corrections applied during execution (qualifications, campaigns, executions, exceptions, handovers, resources field name corrections). No new capability-specific subsystems created; no widened authority grants; staging database authority pattern verified working. Production deployment authorized.** Previous compatibility increment status (retained for reference): `StandardCapabilityDefinitionCatalog` still represents the eight complete compositions as ordinary Definition values with stable IDs `a8300000-0000-4000-8000-000000000001` through `...0008`. New publications now bind generic Definition Type revision 3; new Capability Definitions bind Capability Definition Type revision 3, while revision 2 remains unchanged. Business Capability Instance Type revision 2 remains the Application contract. The installer recognizes the exact strict Initialization-v1 lineage and the older relaxed-v1/generic-v2 lineage, preserves all prior Type/Object revisions, and converges generic Definitions on revision 3. The governed publication, Application and projector paths retain exact Definition/Object revisions, Business-derived Operation identity, expected Application revisions, Command/provenance evidence and constituent/Operation authorization. The projector still requires inspection authority for `BUSINESS_CAPABILITY_INSTANCE_TYPE`; the prior read-only Spearmint snapshot contains no such grant. The existing configuration-install grant targets Type-of-Type and is not treated as Application inspection authority. No grant was added or widened. Validation for this compatibility increment: pinned PHP syntax checks, workspace diagnostics and `bin/target-check.ps1` passed; the target manifest resolved all **171 reviewed files**. The database-independent `CapabilityDefinitionTypeRevisionTest` passed **2 tests / 5 assertions**. The approved `bin/run-tests.ps1` path refused to proceed before PHPUnit because the configured staging-source host is loopback. No database-backed integration, real-clone HTTP acceptance, staging release/provisioning, or post-change database behavior is verified. No staging or production data was written. The available prior clone snapshot contains eight legacy Application-shaped Objects, zero of the eight standard Definitions, and no publisher grant; its values were not changed in this session. No production/target Definition publication, Business Application installation, publisher-authority configuration or real Spearmint state is claimed. Standard Definition IDs/Object revision 1 and Application Type revision 2/Object revision 1 remain intended governed outputs, not current Spearmint evidence. Staging release/provisioning remains blocked until the approved source configuration passes the non-loopback refresh safeguard; the final UI also remains gated on existing Application-Type inspection authority. ## Generic Platform Definition Publication Boundary **Status: GOVERNED PUBLICATION FOUNDATION IMPLEMENTED; LATEST TYPE-HISTORY INCREMENT UNVERIFIED.** The working tree preserves the strict Initialization Definition Type revision 1 and the older relaxed-v1/generic-v2 lineage, appending generic Definition Type revision 3 without rewriting prior Objects. The shared Object repository and bounded validator enforce typed subject values, exact Type revisions, Candidate A `{kind: "object_reference", id, revision}` values, exact retained Object revisions, dependency publication availability, cycle rejection and depth/node/edge limits without executing Workflow or Logic. Existing focused verification predates the current Type-history increment; the approved staging-derived test runner did not reach PHPUnit because its source host was loopback. `definition.publish` is installed as an exact platform Operation and executes through the existing Operation resolver, direct platform AuthorityGrant plus matching Policy, Command identity/fingerprint, coordination lock, expected Object version, GenericObjectRepository and Action Execution/Attempt/Outcome/Event/Provenance Objects. Publication availability is verified from the retained exact Definition revision and matching settled Command, successful Outcome and Event evidence. The explicit `TargetProvisioningRunner` post-owner mode reads non-secret `IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID`, verifies selected database identity, current Genesis/opening and Principal usability, then idempotently installs only the narrow grant and Policy. Installer behavior was integration-tested with an admitted test Principal in the disposable database; no real publisher Principal value was supplied, and no publisher grant or Policy was installed in staging or target. Genesis and immutable platform-opening artifacts remain unchanged. The read-only `/definitions` Explorer lists only exact persisted Definition revisions with successful publication evidence. Selection requires an explicit Object revision; Initialization revision-1 Definitions, release manifests, legacy capability projectors and the eight standard names are not fallback sources. The existing Principal allowlist remains presentation gating, not publication authority. Inspector traversal resolves Candidate A references, reports unresolved/inaccessible/incompatible/unpublished/cyclic/limited results without exposing inaccessible identities, and does not execute Workflow or Logic. Operation input declarations now support type, label, description, requiredness, validation and the six documented source categories. Source-less legacy declarations remain user input; server sources resolve through existing authorized Object/Relationship readers at exact revisions, and caller-supplied overrides are rejected. Focused evidence is recorded under `PersonOrganisationDefinitionTest`, `Idy006BPresentationTest`, `DefinitionPublisherAuthorityInstallerTest`, `OperationInputResolverTest`, `OperationFoundationTest`, and the release/provisioning package tests. No staging data was changed and no deployment was run. **Acceptance limitation:** `.\bin/run-http-acceptance.ps1 -Suite idy010` and the focused `Idy008InstallerTest` were attempted after the runtime changes. Both stop during the existing HTTP-harness fixture setup, before requests execute, because the historical IDY-008 `capability_derivation` declaration contains `definition_revision`, which its retained Business Capability Instance Type descriptor does not declare. This non-conforming release-backed data is explicitly outside Definition authority; neither the manifest nor its descriptor was changed to force it through. The focused `Idy006BPresentationTest` suite independently passed **17 tests / 125 assertions**, including actual published Definition rendering and read-only behavior. No IDY-010 HTTP request assertions are claimed from the blocked run. **External Action authorization and no-network simulation implemented; focused verification passed.** The explicit Option A decision authorizes an external Action against the governed Operation Contract identity: the existing Business AuthorityGrant targets the Operation Type plus exact Operation Object ID, and a matching active Policy must bind that same ID and operation name. No Connection Type or parallel authority system was introduced. Operation Type descriptor revision 1 remains frozen; retained revision 2 adds optional `execution_kind` and `authority_subject`, and existing revision-1 Contracts remain executable. Invocation and Command commit both resolve the exact current active Operation revision and recheck Business membership, Grant and Policy under the existing coordination boundary. `send_email` uses one trusted no-network simulation Provider. Its Command has no mutation effects, fingerprints the Operation ID/revision, validated inputs and source references, and atomically retains Command, Action Execution, Attempt, simulated/not-sent Outcome, Event and Provenance. Evidence reports `network_attempted=false` and aggregate counts; raw recipient, sender and message content are not persisted. Focused evidence: `SendEmailOperationInvocationTest.php` passed **6 tests / 43 assertions**; `ExternalActionAuthorizationTest.php` passed **6 tests / 9 assertions**; and `OperationFoundationTest.php`, `ExternalActionAuthorizationTest.php` and `CreateEnquiryOperationInvocationTest.php` passed **82 tests / 184 assertions**. A combined nine-suite Definition/Operation/opening regression passed **139 tests / 552 assertions** before the final additional privacy assertion; the updated send_email suite was rerun separately. Live providers, credentials, asynchronous external execution, capability authoring/application and all eight Capability Definition contents remain excluded. No staging data or publisher authority was changed and no deployment was run. The IDY-010 fixture limitation and the capability exclusions stated in the earlier Action-foundation snapshot above are historical scope/evidence; they are superseded for Capability Definitions and Business Applications by the current BUILD record at the top of this document. Live providers and asynchronous external execution remain deferred. ## Historical Platform Capability Definition Persistence Audit **Scope note:** this 2026-09-29 audit is a historical snapshot superseded by the Capability Definition and Application Build above. It records the then-current content state and does not describe current implementation status. Its MariaDB availability statement is specific to that dated audit. **Status: NON-CONFORMING PRIOR SLICE; CORRECTED BY DOCUMENTATION, 2026-09-29.** The prior `PlatformCapabilityDefinitionPublisher` persisted one root Object whose payload remained a shallow `supported_constituents`/Operation/View list. That does not satisfy the canonical requirement that a Capability Definition contain the complete recursive composition required to define and operate the capability. It also introduced an undocumented publication path and capability-specific vocabulary/manifest semantics. It is not implementation evidence for a conforming Definition system. Generic Object, Type, revision, provenance, release verification, Business scope and governed configuration mechanics remain reusable where they conform to their canonical owners. The canonical product composition for Sales is now documented in [Business Capabilities](../product/capabilities.md#sales-capability-definition). The other seven standard compositions remain unspecified. This product documentation does not persist or publish Sales. The current documentation reconciliation makes the boundary explicit: there is one Universal Object model, and a Capability Definition is an ordinary platform-owned Definition whose complete composition may contain inline values and recursively contained or referenced Objects serving any semantic role. Data, Workflow, Logic, Relationship, Presentation and Configuration are not separate object systems or mandatory Types. Independent addressability uses the existing Object identity, exact revision, reference and provenance mechanics; containment does not automatically require a new identity. No Capability-specific graph, registry, store, publisher, schema or semantic-role Type is authorized. The eight standard names are documented product concepts. Sales now has a canonical product composition, but no Capability Definition is persisted or published; Sales remains unpublished, and the other seven compositions remain unspecified. The narrow `definition.publish` Operation and configured publisher grant/Policy are implemented and focused-tested, but this does not promote the shallow IDY-008 declarations into semantic Definitions or copy them into platform scope. Platform Definition publication and IDY-008 Business application remain separate activities; IDY-008 must bind an exact Definition identity/revision when one is available and must not mutate the platform Definition. Release IDs, versions and digests remain provenance, not Definition identity. The prior publisher wiring, capability-specific Types/kinds, manifest fixture changes, projector fallback, and test assertions are nonconforming historical implementation, not publication authority; this documentation-only reconciliation does not change or remove runtime code. No complete Capability Definition content is implemented or published; the generic Definition publication foundation is implemented as recorded above. Database-backed verification remains blocked by MariaDB unavailable at `127.0.0.1:3306`; no staging or deployment operation is authorized by this status entry. ### Capability content and publication readiness matrix The following is the current audit of the eight product names. It distinguishes documented product direction from actual authoritative Definition content. A listed Type, Operation or View is an observed shallow constituent or illustrative catalogue concept; it is not a complete Definition and does not establish a publication source. | Capability name | Observed non-authoritative content | Authoritative complete Definition | Readiness | |---|---|---|---| | Sales | Four Types, four Operations, two Views, plus state/transition/relationship declarations; canonical product composition now documented | No persisted/published Definition | Documentation complete; generic foundation runtime implemented | | People | Minimal Person/Organisation Type and View; foundational Definitions are separate | None | No authoritative root | | Products & Services | Offering Type and View only | None | No authoritative root | | Marketing | Campaign Type and View only | None | No authoritative root | | Operations | Operational Work Type and View only | None | No authoritative root | | Projects | Sales-shaped Project Type and placeholder View; non-conforming composition | None | No authoritative root | | Finance & Accounts | Financial Record Type and View only | None | No authoritative root | | Knowledgebase | Minimal Knowledge Item Type and View | None | No authoritative root | Sales product semantics are settled and remain outside this publication-boundary BUILD; they are not reopened here. The generic Definition publication runtime is implemented, but it does not author or publish Sales or the other seven standard Capability Definitions. Their product compositions remain missing, and none may be inferred from `demonstrator.json`, `PlatformVocabulary.php`, `idy-005-vocabulary.json`, `CapabilityProjector.php`, or the historical Sales acceptance fixture; those artifacts remain legacy/configuration/diagnostic evidence, not semantic authority. Automatic publication through Initialization, platform opening, IDY-008, manifests or the historical projector remains **NOT AUTHORIZED**. The implemented `definition.publish` Operation is the governed publication path. The Explorer follows `UI -> published persisted Definition -> explicit Object revision -> bounded recursive inspection`; it does not fall back to legacy capability projections, and it never fabricates the eight standard names. No complete Capability Definition is currently published. **SALES PRODUCT DOCUMENTATION COMPLETE; GENERIC PUBLICATION RUNTIME IMPLEMENTED; CAPABILITY DEFINITIONS NOT PUBLISHED.** No Capability Definition is persisted or published. The generic foundation does not implement Business application or persist Sales. The other seven Capability Definitions remain blocked on their own product compositions. ### Read-only Spearmint staging snapshot audit **Evidence date: 2026-09-30.** The approved staging-to-disposable refresh copied `idio2plat_staging` into `IDY_TEST_IDY002`; all inspection queries ran in a read-only transaction and rolled back. Staging was not modified. The snapshot contains one `Spearmint Design` Business, `5426fb74-f233-4245-81b0-d69a51b7603d`, at Object revision 1. Its value contains only `display_name` and `status`. The snapshot has eight Business-scoped Objects of the historical Business Capability Instance Type. All are revision 1 and marked `active`; all bind `definition_version: 1` and `definition_release_id: business-scoped-bounded-demonstrator-v1`, but none contains `definition_revision`. These are existing legacy configuration records, not evidence of a conforming application of a published Definition. Their exact current values are: | Capability | Instance Object ID | Definition ID | Selected constituent IDs | Operation IDs | View IDs | |---|---|---|---|---|---| | People | `ec73f1f3-1e9e-4520-8a45-b5a5eb12253c` | `7f4f6b8c-3d2e-4f10-8a11-223344556692` | `2c683b18-369c-49f2-8b68-49c348b71ed1` | none | `8d5e4dd9-33bf-4105-b3e6-fbd5c573e764` | | Products & Services | `c53b7b2d-2f04-4c05-a71e-25a2ba79e0c5` | `7f4f6b8c-3d2e-4f10-8a11-223344556693` | `93127e4a-1976-4b08-873a-ac82d3caebfa` | none | `64803380-d18a-4aea-8226-9e339c0541d1` | | Sales | `9eef945f-3e58-4666-a925-9fdbc8e0fa13` | `7f4f6b8c-3d2e-4f10-8a11-223344556690` | `4f37293d-7d1e-4603-90c7-24ac448b0934`, `ded1d467-c054-47f0-b12f-991627e2f83f`, `fc2d9149-f4f9-4e88-9be8-cb32be2da724`, `cce377c5-0876-4092-aa15-487fb319adf0` | `9a3577e7-992e-478c-8f88-16c8e5ffd9fd`, `bdbb900c-e908-476e-8125-2217fc1dc22a`, `fdd2c94b-48a5-4736-811d-36347f33b43b`, `ef9bc082-eb5f-4384-bf1f-805974a51b29` | `4e96e9da-39b5-4b7c-b2aa-0c80199c3fce`, `b99a0004-d276-49be-af86-a4c0500ca621` | | Marketing | `85edfee1-3070-4cb9-afcd-15c07caa0da8` | `7f4f6b8c-3d2e-4f10-8a11-223344556694` | `b94454dd-1c3a-4a54-bebc-0321287ad2d2` | none | `53b60012-3677-447e-92d7-1cc0472277e4` | | Operations | `67ae6005-b3f7-4271-bcce-3dd25c6a2a80` | `7f4f6b8c-3d2e-4f10-8a11-223344556695` | `01de0b95-0d51-4dcf-b20a-15e3585db28b` | none | `56439c37-2c6d-4a17-ab8e-1181ee606908` | | Projects | `fab96ae8-7970-43e3-96f9-e44937db28c4` | `7f4f6b8c-3d2e-4f10-8a11-223344556696` | `cce377c5-0876-4092-aa15-487fb319adf0` | none | `cb6c4900-1c46-4d5e-84fa-8d422eecfdc1` | | Finance & Accounts | `7e01fb2b-2f04-4c05-a71e-25a2ba79e0c5` | `7f4f6b8c-3d2e-4f10-8a11-223344556697` | `98904991-439c-47bb-b529-c46c690c1817` | none | `f768c24f-a620-407b-8bd9-5f1e10da51c8` | | Knowledgebase | `124800f4-99af-4c84-966e-e0add77ffaa6` | `7f4f6b8c-3d2e-4f10-8a11-223344556698` | `0db00058-12a1-4301-99cb-2a8f37a034fe` | none | `f29135f9-a7c2-4c3b-b2f0-0bd5027354eb` | Only the Sales instance references Operations, and those four revision-1 Operation Objects are marked active. The snapshot has two Business AuthorityGrants and two allowing Policies, limited to `platform.inspect_foundation` on Business Type and `platform.install_configuration` on Type-of-Type; it has no Operation-targeting grant or Policy. The four Sales Operations are therefore not authorized for invocation in this snapshot. The capability instances contain no relationship or Policy references, `relationship_index` has zero rows for the Business, and none references a Form. The one View reference on each of the other seven instances and the two Sales View references are persisted IDs, not proof of a usable capability presentation. The platform has only the Principal and Business initialization Definition roots; none of the eight Capability Definition IDs above is a persisted/published Definition. The checked-in `demonstrator.json` is release `business-scoped-bounded-demonstrator-v2` and contains eight shallow platform catalogue declarations plus eight historical `capability_derivation` declarations with `definition_revision: 1`; the retained Business Capability Instance descriptor does not declare that field. This source release also differs from the v1 binding stored in the snapshot. The Explorer requires successful publication evidence for an exact persisted Definition revision, so it does not expose these fixture names as Definitions. **UI trace, not HTTP acceptance evidence:** `CapabilityProjector` reads the JSON release rather than canonical published Capability Definitions and rejects a Business instance whose release ID differs from the loaded release. Against the audited v1 Business values and checked-in v2 release, its availability check returns false; the target shell consequently emits no capability navigation links, the overview suppresses its Marketing projection, and direct capability routes resolve as unavailable. No browser or HTTP acceptance run was performed for this audit. The source `BusinessCreationOperationHandler` currently creates an additional demonstrator Operation grant and Policy for newly created Businesses, while the canonical Business-creation contract specifies only initial Business inspection and configuration authority. Those extra grants are absent from this older staging snapshot. This source/runtime discrepancy is recorded for reconciliation; it is not authority established by the existing capability configuration. **Build gate:** these eight pre-existing records must not be silently upgraded, overwritten or duplicated. The seven non-Sales capability compositions remain undocumented, and the legacy-record disposition has no approved adoption/reconciliation procedure. No Capability implementation BUILD is authorized until those content and disposition gaps are resolved under the canonical owners. No application code, authoritative database state, release artifact or staging data was changed; only the approved disposable snapshot was refreshed. **Disposable rehearsal evidence, 2026-09-30:** On a refreshed `IDY_TEST_IDY002` clone, IDY-008 v3 classified the Spearmint configuration as `conflicting` and issued no declaration Commands. The 45 existing declaration Objects retained their revisions and canonical values; two declarations were absent, and the installer changed zero Objects or Object revisions. A read-only comparison found 34 existing declaration values differ from the checked-in manifest. `TargetProvisioningRunner::reconcileOpening()` also refused a persisted platform-opening effect conflict; the effect transaction rolled back, and the clone was refreshed afterward. No staging data was written. Publisher identity remains unconfigured. These results reinforce the existing build gate; they do not authorize reconciliation, publication or Business application. ## Phase 1 Person and Organisation Definitions **Status: CORRECTED; DATABASE-BACKED VERIFICATION BLOCKED, 2026-09-29.** The existing `InitializationVocabulary` platform path defines distinct revision-1 Person and Organisation Type descriptors and platform-owned object Definitions. Both use the generic `{id, type, value}` model, remain Business-independent, and contain only the intrinsic display-name boundary. Subject-level status and unsupported Person/Organisation initialization workflow kinds are not defined; Definition metadata status remains separate, and Person/Organisation instance creation remains deferred to a later approved domain/capability workflow. No Principal, Business, Membership, Authority Grant, Policy, authentication or capability-specific semantics were added. The IDY-008 demonstrator release now contains one Business-scoped Person-to-Organisation relationship Type using the existing directed, many-to-many, unique-active relationship contract. The trusted v2 manifest digest was updated in the existing CLI and target release-verification maps. The existing Business-scoped `person_or_organisation` Type, People View, capability instance and Spearmint configuration were left unchanged; no adoption, migration or retyping occurs. Focused integration coverage covers platform ownership, revision/schema identity, display-name-only subject schemas, generic instance persistence, absence of authority side effects, relationship endpoint declaration and legacy coexistence. The existing Definition contract now permits Definitions without an initialization workflow kind; Principal and Business retain their established workflow kinds, and `InitializationService` is unchanged. The corrected vocabulary file is diagnostic-clean under the pinned PHP 8.3.33 environment, and the unchanged manifest remains covered by the prior JSON validation. The local disposable MariaDB listener is unavailable on `127.0.0.1:3306`; the staging-refreshing wrapper was not used, so database-backed behavior and installed-state conflict checking remain unverified. Contact Method, Role, Responsibility and capability-specific Definitions remain **NOT BUILT**. ## Universal Foundation and Marketing Reconciliation **Status: DOCUMENTATION-ONLY RECONCILIATION; SUPERSEDED BY THE FOUR-ROLE CONTRACT.** The canonical owners now explicitly state that Data, Logic, Workflow and Presentation are the four semantic roles of the universal Object model. Definitions describe/configure object composition made from those roles and their constituent structure; Business, capability, Marketing, network, variable, calculated-value, knowledge, analytics, learning and AI terminology does not introduce another primitive. Objects may gain, replace or lose constituents through normal governed execution, including ordinary Presentation composition. **Historical snapshot, superseded for implementation status by the current Definition publication record above.** The statement below that foundational Definition implementation had not begun accurately records the state on 2026-09-29 only; it is not the current implementation status. The reconciliation defines retained-reference and resolved-value assignment as two semantics of one assignment/mutation mechanism. Retained references preserve an authoritative source relationship and derive current value from it; resolved assignments evaluate the source at assignment time and retain the resulting value, with provenance/causal evidence where supported. Either form can later be replaced by normal Data/Workflow/Logic mutation. Marketing is documented as a future capability/domain whose network emerges from ordinary objects and relationships, without a bespoke graph, campaign engine, network primitive or capability mechanism. Business-specific configurations may inform reusable derivatives or platform patterns only through explicit human authority. This change modified canonical documentation only. No application code, database schema or data, fixture, test, UI, deployment configuration, release artifact, staging environment or production environment was changed. D01-D10 and the existing unnumbered three-role/reference clarifications remain authoritative; no new architecture decision was introduced. Foundational-definition implementation and planning were not begun. Existing historical implementation evidence, including `capability_derivation` terminology, remains unchanged and is not runtime evidence for this reconciliation. ## Derivation, Business Network and Access Documentation Reconciliation **Status: DOCUMENTATION-ONLY RECONCILIATION; NO RUNTIME IMPLEMENTATION OR VERIFICATION, 2026-09-27.** The canonical documentation now makes explicit the cross-cutting invariant to store facts, evidence, relationships and history, then derive conclusions and conditions from them rather than introducing duplicated classifications or flags. The reconciliation preserves separate Business existence, network participation, Principal association, authority, subscription/entitlement, capability existence and permitted operation depth. The updated owners describe legitimate relationship-mediated Business participation and information accumulation before Principal association; authority to act for a Business without treating authority as existence; subscription as an operational/access input rather than authority or capability existence; exploratory constrained authority without quotas, tiers, pricing, a final access matrix or a `remaining` counter; holistic permitted capability presentation with restricted deeper operations; and competing assertions whose provenance, standing, scope, temporal context and history remain intact. The 34-employees versus 21-employees example demonstrates deterministic contextual derivation without destructive replacement or a generic `verified`/`unverified` classification. This reconciliation changed only canonical documentation and this status record. No application code, schema, migration, test, release package, database, staging environment, deployment configuration or archived source snapshot was changed or executed. No D01-D10 decision was reopened, no D11 or other numbered decision was created, and no runtime behavior is claimed or verified by this entry. Remaining governance questions are intentionally deferred: eligible network introduction/evidence sources and retention rules; the exact limited inspection and capability-depth matrix under inactive or unconfirmed entitlement; the constrained-authority dimensions and approval responsibilities needed by real operations; the evidence threshold for Principal association or representation; and which derived determinations require live recalculation versus permitted materialization and what historical reconstruction guarantee applies. ## Definitions Readiness Documentation Consolidation **Status: DOCUMENTATION-ONLY CONSOLIDATION; DEFINITIONS NOT IMPLEMENTED, 2026-09-27.** The canonical owners now provide an implementation-ready conceptual boundary for foundational Definitions without introducing a Definition primitive or new architecture decision. Definitions are addressable descriptive objects within `{id, type, value}`; they may describe recursive constituent structure, relationships, applicable Types, configuration requirements, workflows, Logic, Operations and appropriate presentation configuration. Discovery, validation, publication, adoption, configuration/use and later revision proposal remain distinct governed activities. **Historical snapshot, superseded for implementation status by the current Definition publication record above.** The following non-implementation statement records the state on 2026-09-27 only; complete Capability Definition content and Business application remain deferred. The documentation also records derived missing-configuration and contextual validity/uncertainty, progressive Business configuration, derived attention, epistemic presentation, model-driven AI configuration with manual parity, capability composition, subscription explanation and longer-term Business DNA learning direction. Definition changes do not silently mutate existing Business configuration or instances; explicit adoption, review, reconfiguration or a future governed migration process is required. This entry does not claim Definition tables, CRUD, APIs, editors, onboarding, AI configuration, network features, migrations, schema changes or runtime behavior. Those remain the next implementation stage or explicitly deferred future/open design work. ## Superseded Capability Definition -> Business Capability Instance Slice **Status: HISTORICAL EVIDENCE ONLY; NON-CONFORMING TO THE RECONCILED DEFINITION CONTRACT, 2026-09-29.** The earlier slice demonstrated plumbing around a shallow manifest composition, but it did not prove a platform Capability Definition containing the complete recursive composition required by the canonical owners. Its test and HTTP results remain historical behavior evidence only and must not authorize extension of the old model. ### Added - Added two ordinary platform Type descriptors to the existing IDY-005 vocabulary: standard Capability Definition and Business Capability Instance configuration. No database migration or capability-specific table was added. The persisted Business Type UUID remains `7a4f6b8c-3d2e-4f10-8a11-223344556691`; its current executable symbol and declaration kind still contain historical `Derivation` terminology, which is implementation debt for the next bounded code cleanup. - Extended the existing IDY-008 demonstrator release with shallow platform and Business capability declarations. This content is now treated as legacy fixture evidence, not as the semantic Definition or an accepted `capability_derivation` layer. - Reused the existing IDY-009 Enquiry, Qualification, Decision and Project Types, state values, Operations, Views, authority/policy grants, `OperationInvocationService`, `CommandHandler`, authorized object reader and server-rendered target presentation. - Added the read-only `CapabilityProjector`, the authenticated `/capabilities/marketing` route and the overview/navigation projection. The view presents standard identity, Business Capability Instance configuration, calculated attention, constituent state, authorized context links, permitted actions and configuration mechanics. Actions are omitted unless the existing Operation authorization check permits initiation. ### Evidence - `.\bin\run-tests.ps1 tests\Integration\Idy008InstallerTest.php tests\Integration\Idy006BPresentationTest.php tests\Integration\DemonstratorQualificationOperationInvocationTest.php`: **40 tests, 246 assertions, 0 failures, 0 errors** on PHP 8.3.33/PHPUnit 11.5.56 with the isolated MariaDB fixture. - `.\bin\run-http-acceptance.ps1 -Suite idy009`: existing IDY-009 HTTP flow plus the Marketing holistic view, constituent projection and submitter/reviewer action-surfacing checks passed; the acceptance server shut down cleanly with no runtime diagnostics. - Installer assertions prove the platform Definition remains release-owned, is not copied into Business scope, the Business Capability Instance references its stable Definition identity, and the source manifest remains unchanged after installation. ### Not added Capability evolution, future Derivation, promotion of Business configurations into standards, automatic standard mutation, cross-Business learning/convergence, a broad capability catalogue, a generic Capability Engine/Runtime/Store, a fourth semantic role, a separate capability database, AI configuration, or a capability-specific mutation/authority path remain **NOT IMPLEMENTED**. The current slice is one Marketing composition over the bounded IDY-009 process; it does not claim general capability adoption, migration, evolution or future Derivation functionality. ## Capability Projection Genericity Correction **Status: HISTORICAL PROJECTION EVIDENCE ONLY; NOT PROOF OF COMPLETE DEFINITION IMPLEMENTATION, 2026-09-29.** The existing projector demonstrated reusable projection plumbing over the prior shallow fixture, but it does not establish an authoritative recursive Definition composition. ### Added - Attention is now interpreted from bounded release presentation configuration rather than hard-coded Enquiry/Qualification state rules. No attention persistence, queue, notification store or attention engine was added. - Capability resolution accepts an explicit capability key derived from the configured definition label; the runtime no longer selects the first manifest definition. - Operation references resolve the revision declared by the trusted release, and View context is read and linked at its exact release revision. Later durable revisions do not silently replace the pinned projection. - State interpretation uses the existing authorized PresentationCatalog boundary, and configuration runtime IDs use the shared resolver rather than duplicated hashing logic. - Added a synthetic `Work Items` capability fixture with a different constituent type, `blocked` state, View, Operation, configured attention rule and Business Capability Instance configuration. It projects through the same projector and template without Marketing/IDY-009-specific code changes. ### Evidence and limits The focused synthetic and regression suites passed **41 tests and 261 assertions**; the complete IDY-009 HTTP acceptance suite passed with no runtime diagnostics. The proof establishes reusable projection/configuration plumbing for a second capability shape, not a complete second product capability. Durable platform Capability Definition lifecycle, evolution, convergence, promotion, cross-Business learning, AI-driven configuration and the broad capability catalogue remain **NOT IMPLEMENTED**. ## Capability and UI Model Documentation Reconciliation **Status: DOCUMENTATION-ONLY RECONCILIATION; NO RUNTIME IMPLEMENTATION OR VERIFICATION, 2026-09-26.** Capability definitions are recorded as platform-owned reusable definitions, with Business-controlled deviations expressed through governed Business-scoped configuration and instances. Capabilities, capability definitions and the conceptual UI presentation direction have been explored and agreed at the architectural level: deterministic capability composition, holistic and attention-first presentation, progressive disclosure, consequence-aware authority, epistemic distinctions, dataset ingestion versus live integration, operational activity summaries and manual/AI parity remain documented direction. This work changed no application code, schema, migration, test, release package, database, staging environment, deployment configuration or archived source snapshot. The exact UI elements and complete presentation vocabulary remain to be explored. Attention surfaces, watched objects, broad onboarding, dataset ingestion, recommendations, cross-business patterns, future capability discovery, analytics, integrations, AI and the wider capability catalogue remain product and architectural direction, not implemented feature evidence or MVP completion claims. ## Four Semantic Object Roles and Generic Composition **Status: IMPLEMENTED; FOCUSED VERIFICATION PASSED, 2026-10-06.** The authoritative [core object model and authority](../architecture/core-object-model-and-authority.md#four-semantic-object-roles) contract defines exactly four semantic object roles: Data, Logic, Workflow and Presentation. These roles express business meaning within the existing universal `{id, type, value}` model; they are not D02 Type values. The `type` continues to identify domain meaning, including Business, Customer, Invoice and Workflow Definition, while Event, Command, Attempt and Outcome remain addressable same-model infrastructure records. The roles compose recursively in one global object graph; they are not separate stores, schemas, engines or application subsystems. The generic Definition path now supports a data-defined semantic role and typed named semantic inputs using exact Object references or inline typed values. Validation covers role, input identity, expected Type descriptors, cardinality, required/optional presence, exact revisions, Type compatibility and existing recursive composition/cycle limits. It does not execute Logic or Workflow, resolve Presentation bindings or create role-specific persistence. The documentation reconciles the roles with existing Relationships, revisions, authority, governed mutation, Command/Attempt/Outcome, provenance, Events, Workflow Definitions/Executions and optional AI. Search, requests, inputs, configuration, calculations, automation, To Dos and AI are represented as compositions, infrastructure records or projections rather than additional semantic roles. Logic evaluation, Presentation-to-Logic consumption, Workflow execution and Dashboard migration remain out of scope. No schema, migration, role-specific table, evaluator or Dashboard migration was added. The focused integration suite verifies the generic validation boundary; it is not runtime verification of Logic execution, dependency evaluation or Presentation-to-Logic consumption. ## External Valuation Page Responsive Correction **Status: IMPLEMENTED; LOCAL BROWSER VERIFICATION PASSED, 2026-09-24.** The supplied `c:\Users\stuar\Downloads\index.html` page was corrected without changing its HTML content or JavaScript. At widths up to 768px, the sidebar is no longer sticky and is bounded to the viewport with its own vertical overflow, allowing the main content to follow it in normal document flow. The sidebar scrollbar is hidden with `scrollbar-width: none`, `-ms-overflow-style: none` and a scoped `::-webkit-scrollbar` rule, while scrolling remains enabled. The app grid and main column now accept narrow widths (`minmax(0, 1fr)` and `min-width: 0`), and mobile main padding/gap were reduced to avoid unnecessary horizontal pressure. Source inspection verified that no content text, data, links, controls or JavaScript changed. Local browser verification on the supplied file passed at 1440, 768, 430 and 375px viewport widths: the main column was reachable at mobile widths, the document reached its end by normal page scrolling, the sidebar retained independent scrolling, the sidebar scrollbar computed as hidden, and the document had no horizontal overflow. Existing control behavior was not exhaustively exercised; no staging deployment or remote-device verification was performed. ## Business Creation, Configuration and Operational Initialization ### Temporary Business Configuration Workspace **Status: IMPLEMENTED; FOCUSED VERIFICATION PASSED, 2026-09-24.** The authenticated `/business-configuration` target surface is now a temporary development/admin workspace for the A+B slice: it reads the actual platform Business Definition and revision, renders Definition-derived constituent requirements, shows the current Business and matching constituent object instances/values with available technical revision/provenance references, and links to the existing governed initialization surface for value creation/update. The read projection does not call `InitializationService::start()` and therefore does not admit an initialization workflow or create initialization event, provenance, dispatch or execution records. The workspace reuses the existing server-resolved Business context, Membership, `platform.install_configuration` authority/Policy boundary, Business inspection authority, object/revision repository and existing `InitializationService` mutation path. It contains no email comparison, direct SQL mutation, second Business form, Definition Save Operation or generic JSON/table editor. Definition structure editing (C) and operational demonstrator initialization (D) remain explicitly unsupported/excluded; the workspace does not call `provisionDemonstrator()` or create Enquiry, Qualification, Decision or Project records. The current stored Business Definition is rendered at runtime, so a `website` field appears only if the authoritative Definition contains it. Focused verification on the pinned PHP 8.3.33/PHPUnit 11.5.56 runner passed `PrincipalAdmissionBusinessCreationTest.php` with **7 tests, 147 assertions, 0 failures and 0 errors**, and passed the adjacent `DefinitionDrivenInitializationTest.php` with **3 tests, 19 assertions, 0 failures and 0 errors**. The read-only target release check passed with **155 resolved files** after adding the workspace runtime class to the reviewed boundary. No staging deployment, staging database mutation or staging Business fixture was used for this build. ### IDY-007C lease and platform provisioning corrections **Status: IMPLEMENTED; FOCUSED AND TARGET-REGRESSION VERIFICATION PASSED, 2026-09-24.** `WorkflowDispatchLeaseService::claimNext()` now treats a rejected trusted workflow transition as no claim and commits the unchanged eligible state, so a conditional resource-claim rejection cannot be reported as a successful lease. The strict `ConfiguredResourceClaimGuard` comparison against MariaDB `UTC_TIMESTAMP(6)` is unchanged. IDY-007C dispatch and finalization fixtures now derive their supplied times from `SELECT UTC_TIMESTAMP(6)` rather than historical timestamps; expiry and fencing assertions remain exercised through the existing narrow `DateTimeImmutable` seam. Normal runtime construction is now assembly-only: `TargetRuntimeCompositionRoot::fromExisting()` does not install platform vocabulary, governance or evidence. `TargetProvisioningRunner` owns the complete platform installation sequence, including `InitializationVocabulary::installPlatform()`, and serializes it with the existing `runtime_coordination` row lock inside one transaction. This preserves deterministic fixed platform identities and idempotent opening behavior without duplicate-key suppression or schema changes. Affected test fixtures now invoke the platform-opening installation owner explicitly. The bounded sequential workflow interpreter is now assembly-wired through `TargetRuntimeCompositionRoot::workflowInterpreter()`. A condition node may reference an exact Logic Definition revision; both the interpreter and the trusted workflow Operation handler resolve it through `GenericLogicEvaluator` against the pinned execution subject, then retain the existing governed Operation, lease, expected-version, authority/policy and evidence boundaries. The validator accepts only a positive UUID/revision pair for this reference. This remains a bounded step surface: no general worker, scheduler, queue, wake/recovery, retry/replay, parallel execution, approval wait, compensation or external-effect guarantee is claimed. The required focused runner could not be executed for this change because the approved staging-to-test refresh failed with MySQL error 2002: MariaDB was not listening on `127.0.0.1`. No independent database was created or used. Changed PHP files passed `php -l`; database-dependent workflow and Logic behavior remains unverified in this environment. Evidence: `Idy007CDispatchLeaseTest.php` passed **10 tests / 49 assertions**; `Idy007CFinalizationTest.php` passed **19 tests / 98 assertions**; and the requested target regression trio (`Idy006BPresentationTest.php`, `PrincipalAdmissionBusinessCreationTest.php`, `StagingProvisioningPackageTest.php`) passed **25 tests / 268 assertions**. The canonical `./bin/run-tests.ps1` invocation completed **413 tests / 2,104 assertions** but was not green: it reported one cross-suite assertion failure and eight environment/database-state errors caused by missing `workflow_dispatch`, `platform_opening_applications` and `schema_migrations` tables after the local test-database reset sequence. Full-suite certification is not claimed. No staging deployment, staging configuration change or production operation was performed. ### Standard Definitions Explorer and Business navigation **Historical snapshot (2026-09-29), superseded by the current implementation and acceptance record above.** The BUILD-authorization requirement below records the decision state at that date only; it is not a current blocker. The generic Definition publication, exact-revision Explorer and simulation-only Action foundation are now implemented and focused-tested. Complete Capability Definition content and Business application remain deferred as stated in the current record. **Status: PARTIAL EXPLORER INFRASTRUCTURE; CAPABILITY SOURCE AND CONFORMANCE NOT ACCEPTED, 2026-09-29.** The Definitions Explorer is an intentionally supported target-runtime/platform-control surface for authenticated platform diagnosis and inspection. The authenticated target shell exposes a read-only `/definitions` page only to Principals whose UUIDv4 appears in the server-side `IDY_TARGET_DEFINITIONS_PRINCIPAL_IDS` allowlist. Missing, malformed or non-matching configuration fails closed; ordinary Business users and non-allowlisted Principals remain denied. The Explorer is not development-only, is not generally available to Business users, and is not an authoring or lifecycle surface. The previous five-file runtime/Explorer diff changed catalogue wiring toward persisted platform Definition Objects, added Object revision links, and added an `Explore Definitions` affordance. That diff has not been accepted as conforming Capability Definition architecture. The current persisted Initialization path supplies only foundational Definitions such as Principal, Business, Person and Organisation; the eight standard Capability Definitions are not established as complete canonical persisted Definitions. The Explorer must follow `UI -> Explore Definitions -> canonical persisted Definition -> recursive composition -> Object inspection` when that canonical source exists. It must not substitute a manifest projection merely because a persisted Capability Definition is unavailable, and it must never execute Workflow or Logic during inspection. Inferred reference shapes and revision fallback are unsupported. The implementation path for conformance is now specified in [Implementation Architecture](architecture.md#universal-definition-and-action-foundation-plan); a separate runtime BUILD authorization is required before changing the existing runtime/Explorer slice. The `StandardDefinitionCatalogue` is a read-only presentation boundary. It validates selection by source discriminator plus native identifier, derives structure at read time, follows only declared references, labels release-component scope boundaries, and reports unresolved references, cycles and explicit depth/node/edge truncation outcomes. Its bounds are depth 6, 100 nodes and 200 edges. It does not call Business authorization or relationship traversal, create a hierarchy/table, execute workflows or mutate objects, revisions, relationships, commands or events. The Business selector and Business Configuration workspace remain available. `Manage` resolves to `/objects/`; the boundary requires the requested object to be the selected Business and revalidates Business membership before rendering its minimal read-only detail. Capability navigation retains only `Overview`; `Businesses` and `All records` were removed. Evidence: PHP lint passed for all changed PHP files; `Idy006BPresentationTest.php` passed with **16 tests, 104 assertions, 0 failures and 0 errors**; `bin/run-http-acceptance.ps1 -Suite idy010` passed all listed checks; and the pre-correction `bin/target-check.ps1` passed at 155 files. The corrected 159-file target boundary is verified in the release evidence below. No staging deployment, production configuration change, Genesis change or database schema change was performed. The existing Business selector and Business Configuration workspace remain available. Evidence for this build: PHP lint passed for all changed PHP files, `git diff --check` passed, and `bin/verify-ui-structure.php` passed all structural checks. The requested `.in un-tests.ps1 tests\Integration\Idy006BPresentationTest.php` invocation did not reach PHPUnit because the required staging-derived local database refresh could not connect to MySQL on `127.0.0.1:3306`; no application assertions are claimed from that run. No staging deployment, production configuration change, Genesis change or database schema change was performed. **Status: INITIALIZATION MECHANISM IMPLEMENTED; DATABASE-BACKED INITIALIZER EXECUTION NOT VERIFIED, 2026-09-23.** The phases are deliberately separate. The governed `business.create` Operation creates the Business, creator Membership, explicit inspection/configuration authority, explicit Enquiry-demonstrator operation/mutation authority, Policies and provenance atomically in [BusinessCreationOperationHandler](../../app/Runtime/Operations/BusinessCreationOperationHandler.php). The trusted IDY-008 release in [demonstrator.json](../../database/configuration/idy-008/demonstrator.json) remains reusable configuration only: it installs the Business-scoped Types, States, Transitions, Relationship Types, Operation Contracts, Views and Workflow declarations and does not contain operational instances. That absence is intentional; the subsequent generic initializer creates operational instances through those installed Operations. The generic operational entry point is `InitializationService::provisionDemonstrator()` in [InitializationService](../../app/Runtime/Initialization/InitializationService.php). It requires an existing Business, authenticated Principal, installed IDY-008 Operation Contracts and explicit operation inputs. It invokes `create_enquiry`, `submit_qualification`, `decide_qualification` and `create_project_from_qualification` through [OperationInvocationService](../../app/Runtime/Operations/OperationInvocationService.php), so each phase uses the existing Command, validation, authority, Policy, revision, provenance, event and outcome boundary. The approved runtime values are supplied as ordinary initialization inputs rather than a second seed format; the operation declarations remain the authoritative structure and the existing demonstrator fixture/test vocabulary remains the source of the bounded Enquiry values. The method creates an unmatched Enquiry, a related Qualification and their state progression. It returns `awaiting_review` when no separately authorized reviewer is supplied. With an explicitly supplied reviewer who has the ordinary Business membership, operation grant and Policy, it records the Decision, creates the Project and establishes the four ordinary Project relationships (Qualification, Enquiry, Qualification back-reference and responsible Principal), returning `provisioned`. The reviewer rule remains enforced by the existing Decision handler; initialization does not bypass it or manufacture a reviewer identity. Retry safety is implemented by deriving initialization Command IDs and demonstrator-created object/relationship IDs from stable Business/step/input or Command identities. Matching retries therefore reuse the existing Command result and object identity; changed input produces the normal Command fingerprint conflict. The target composition root registers the existing Project handler. The mechanism is reusable for any Business with the approved configuration and explicit authority; it contains no Business-name branch, Spearmint identity or direct SQL mutation. Execution evidence remains **INCOMPLETE** in this environment. The disposable runner stopped before application execution because two repository migration files share the `0013` migration identity. The focused integration runner reached the initializer fixture but its final result was not exposed with usable error detail after the permitted retry; therefore no database-backed `provisioned` result or idempotent retry is claimed here. The implementation test now uses the existing Business-scoped reviewer fixture and does not seed operational records directly. No staging or production data was used or changed. ## Staging Business Purge Implementation **Status: IMPLEMENTED / EXECUTED / VERIFIED FOR STAGING, 2026-09-23.** [bin/purge-non-spearmint-businesses.php](../../bin/purge-non-spearmint-businesses.php) is a CLI-only staging boundary that requires explicit staging context, a validated non-production database identity, the exact `Spearmint Design` display name to resolve uniquely, and the `--execute` flag before mutation. Without `--execute`, it performs only a dependency inventory. [BusinessPurgeRepository](../../app/Staging/BusinessPurgeRepository.php) deletes dependent index/dispatch rows, revisions and objects in a transaction, refuses cross-Business relationship/workflow references and verifies that exactly one `Spearmint Design` Business remains. PHP 8.3.33 syntax checks and editor diagnostics passed for both changed PHP files. The staging dry run resolved four Businesses: `Spearmint Design` (`5426fb74-f233-4245-81b0-d69a51b7603d`) plus `Promise Money`, `Idiosyncrasy` and `Cottonridge`. With explicit operator confirmation, the execute run removed the three non-Spearmint Businesses, six objects and six revisions per Business, with zero relationship, event, transition, command or workflow index rows. An independent read-only verification then confirmed exactly one remaining Business, zero purge targets and zero dangling indexed/workflow dependencies. No Principals were deleted, legacy `organizations` was not touched, and no production operation was performed. This is an explicit staging cleanup exception to the current demonstrator guidance to retain addressable Business history; it is not a general production deletion contract and has no backup/recovery evidence. ## Principal Lifecycle, Profile and Authenticated Business Plan **Plan status:** DOCUMENTATION-ONLY ARCHITECTURE/DISCOVERY, 2026-09-22. No application code, migration, UI implementation, email delivery, database mutation or staging deployment is claimed by this section. **Clarification, 2026-11-02 (the original text below is retained unchanged as dated history):** "Principal" below means User (legacy Type name). Statements below that tie `business.create` or the `Businesses` navigation to entitlement ("entitlement-aware additional Business creation", "any applicable subscription entitlement", "entitlement/grant-gated creation/onboarding") are superseded: `business.create` is free and never entitlement-gated; only Business-scoped operational use is intended to be entitlement-gated, as future architecture that is not implemented (all Businesses are currently treated as active). See [subscriptions and entitlements](../architecture/subscriptions-and-entitlements.md). ### Current-state assessment The new runtime already has the canonical Principal-first sequence `registration -> confirmation -> authentication -> bounded onboarding -> business.create`. Registration creates a pending typed Principal, separate normalized email identity, protected credential material and a hashed, 24-hour, single-use confirmation challenge. Confirmation is transactionally bound, expires, rejects replay/mismatch/concurrent losers, activates the Principal and issues only the platform-scoped onboarding grant for `business.create`. Authentication establishes session identity separately from authorization. Governed Business creation is platform-scoped, server-owned and atomic: it creates the Business, creator Membership, initial grants/Policies and provenance; Genesis creates none of these. Existing focused evidence covers this bounded JSON/runtime lifecycle and the zero-Business HTML onboarding slice. The missing or incomplete surfaces are email transport and the email-link UX, profile Operations and revisions, protected profile-image storage/reference handling, the persistent top-right Principal control, unified authenticated `Businesses` navigation, entitlement-aware additional Business creation, and the focused browser/integration tests for those surfaces. The current target confirmation template's token textarea is a contract mismatch with the intended normal email-confirmation experience. The legacy profile/avatar controller uses the old application schema and is not implementation evidence for the new platform. ### Architecture decision and lifecycle specification No new D-number is required. Under settled D01/D02/D05/D09 boundaries, the Principal remains a first-class universal object. Display name and approved personal fields are typed Principal values with retained revisions. Authentication email remains a protected `principal_identities` association, not a copied generic property; credentials, confirmation verifiers, session material and security identifiers remain outside generic object retrieval. A profile image is an addressable Media/Asset object/reference; binary bytes remain in protected storage and are never embedded in a generic primitive or exposed as a public authority-bearing URL. The intended lifecycle is: registration creates pending state and requests a confirmation message; the user follows a purpose-bound, expiring, single-use email link; confirmation atomically marks the identity/Principal active and issues only bounded onboarding authority; authentication establishes a session; the authenticated shell exposes the Principal control and `Businesses`; authorized Business identities are listed; `business.create` is available only under the platform grant/Policy and any applicable subscription entitlement; the operation creates the Business and initial administration atomically; profile reads/edits use the Principal object and shared Command boundary; logout destroys/revokes the session. Before confirmation there is no application authentication, Business selection or Business creation. A confirmation challenge is never a general login credential. Duplicate identities return controlled non-enumerating conflict; resend creates a fresh challenge subject to rate limits, while old/consumed/expired challenges remain unusable. Delivery failure or unknown outcome leaves the Principal pending. Business identity remains independent from Principal identity, creator provenance, Membership, AuthorityGrant and subscription. A Principal may administer multiple Businesses where Membership and Policy permit it; a Business may have multiple Principals. There is no special first Business or Genesis ownership. Inactive subscription entitlement blocks Business-scoped operational execution but does not delete Business state or revoke authority. The server resolves Principal, Business, membership, grants, Policies, image ownership and Operation revision; the browser supplies none of those security decisions. ### BUILD Slice 1 evidence: admission confirmation link **Status: IMPLEMENTED and VERIFIED for the bounded admission slice.** The target runtime now separates confirmation-message delivery from Principal admission through an injectable `ConfirmationEmailDelivery` port. Registration commits the pending Principal and challenge first, then requests a confirmation email; JSON and HTML registration responses expose only the Principal identifier and delivery outcome, never the raw challenge. The native target adapter builds the purpose-bound `/confirm?token=...` link, while integration fixtures use a recording adapter. GET confirmation invokes the existing governed `principal.confirm` path, preserving expiry, one-use, locking, activation and onboarding-grant semantics. The manual token textarea and POST token flow were removed from the target confirmation view. PHP 8.3.33 syntax validation passed for the changed runtime and test files. The local-only refresh path was repaired to read staging with `mariadb-dump`, import the dump through client standard input, and avoid staging `CREATE DATABASE`/`USE` statements. Each refresh forcibly drops and recreates only the designated local PHPUnit database, making staging authoritative for local state. The PHPUnit bootstrap explicitly allows migration-ledger checksum mismatches for this snapshot path; strict checksum enforcement remains the default for other `MigrationRunner` callers. On 2026-09-22, `./bin/run-tests.ps1 tests\Integration\PrincipalAdmissionBusinessCreationTest.php tests\Integration\PrincipalAdmissionHardeningTest.php` refreshed local `IDY_TEST_IDY002` from staging `idio2plat_staging` at `78.129.220.19:3306`, then passed **9 tests / 143 assertions, 0 failures, 0 errors**. The refresh reads staging only; no state changes are sent to staging. No staging deployment was performed. Profile fields, profile image handling, persistent account control, logout redesign, Businesses navigation and Business creation UI remain **NOT BUILT** in this BUILD. ### Required implementation sequence 1. Add the smallest schema/runtime support for profile revisions, approved profile Operations and protected Media/Asset metadata/reference, preserving the generic object/revision model and identity tables. 2. Add the admission communication adapter/template and email-link confirmation flow, with redacted outcomes, expiry/replay/rate-limit handling and no raw challenge in normal API/HTML responses. 3. Add authenticated profile projection and self-service display/profile-field mutations through `OperationInvocationService`/`CommandHandler`; add image upload, safe rendition, replacement and removal handling. 4. Extend the target shell with one responsive top-right Principal control and `Businesses` navigation, including no-Business state, server-resolved Business list and entitlement/grant-gated creation/onboarding. 5. Preserve the existing governed `business.create` handler and Business/Membership/Policy model; do not add an Account/Tenant owner or Genesis path. 6. Add focused unit/integration/HTTP/UI acceptance evidence, then update this status with exact code revisions, commands, environments, results and limitations before treating any part as VERIFIED. ### Risks and genuine unresolved decisions The current contracts do not yet select an email provider/transport, exact message template, email-change/re-verification Operation, password recovery contract, secondary-email cardinality, final Media/Asset physical store or final profile-field vocabulary. These are implementation/product decisions that must be explicitly approved within existing owners; they must not be inferred from the legacy profile. The core identity/profile boundary, confirmation semantics, Business authority model, shared mutation path and entitlement gate are settled. ### Contract and test implications The eventual evidence must cover registration state and duplicate handling; email delivery accepted/failed/unknown outcomes; expired, replayed, mismatched and concurrent confirmations; authentication denial before confirmation and session/logout behavior; profile read and authorized self-mutation with revisions/provenance; invalid and unauthorized image upload/read/replace/remove; persistent desktop/mobile shell behavior and keyboard access; authorized/no-Business/multi-Business navigation; Business association and server-owned creation; entitlement suspension; cross-Business isolation; Command idempotency/conflict; and non-disclosure of credentials, challenge material, storage paths and unauthorized objects. Browser checks must exercise the email-link path rather than a token-paste workaround. ## Local PHPUnit Staging Snapshot Mechanism **Status:** IMPLEMENTED / SAFETY-PATH VERIFIED; DATABASE REFRESH NOT EXECUTED [bin/refresh-test-database-from-staging.ps1](../../bin/refresh-test-database-from-staging.ps1) provides the one-way local snapshot operation. It reads missing staging connection values from the ignored local `.env.local` file without overriding existing process `IDY_TARGET_DB_*` values, verifies that the source is non-loopback and is not the fixed local test database, exports the source with the pinned MariaDB dump client, recreates only `IDY_TEST_IDY002` using the existing local administrative configuration, and imports the dump with the local test user. Temporary dump and credential files are created outside the repository and removed on completion or failure. The script does not run migrations, Genesis, provisioning or fixtures and does not alter staging. Every invocation of [bin/run-tests.ps1](../../bin/run-tests.ps1) now refreshes `IDY_TEST_IDY002` from staging before configuring and invoking PHPUnit; if refresh fails, PHPUnit is not run. PowerShell parsing, `.env.local` configuration validation and the missing-staging-input guard passed on 2026-09-22. A clean focused PHPUnit invocation reached the refresh command but returned a native MariaDB/PowerShell error before PHPUnit; no completed snapshot or test result was recorded. ## Persisted Presentation Object Graph Migration BUILD **Evidence date:** 2026-10-05 **Scope:** replacement of capability-specific presentation assembly with exact persisted Presentation Object graph references. Capability presentation is now bound through persisted Presentation Object roots and recursively projected into `RenderablePresentation.elements`. The removed `presentation_items` configuration, capability card assembly, collection/item compatibility arrays and capability-specific summary projection are not production presentation authorities. Remaining verification is tracked by the focused renderer and integration checks below; the staging-backed test runner remains subject to the pre-existing `relationship_index` cleanup failure. ## Surface UI Standard and Stylesheet Integrity BUILD **Evidence date:** 2026-09-22 **Scope:** documentation authority and source-integrity cleanup only. No visual surface reconstruction, route, authentication, Business authority, object, Command/Operation, database or staging change was performed. ### Stylesheet contamination Read-only inspection found operational `Build Mode` prose prepended to the tracked [target/style.css](../../target/style.css), followed by the legitimate target CSS. The target layout links `/style.css`, so this was a real target source inconsistency rather than merely a package note. Git inspection found `target/style.css` and [release/target-release.json](../../release/target-release.json) tracked. The former `release-staging/`, `--help/` and `var/` copies were generated or package artifacts and are not authoritative source; they have now been removed. No stylesheet generator or derived-file declaration was found, and the source file history contains no later stylesheet-specific correction. The repair removed only the unrelated operational prefix from `target/style.css` and preserved the existing target CSS beginning at `:root`. The target layout's `/style.css` reference remains unchanged. Package copies were not regenerated or independently edited; they require regeneration through the normal release/package process before being treated as current artifacts. No staging or production deployment occurred. ### Documentation authority established [docs/implementation/ui-system.md](ui-system.md) is now the authoritative current Surface UI Standard, version 0.1 dated 2026-09-22. It records evidence-backed brand values, unresolved design choices, semantic token roles, typography, shell, admission, components, responsive behavior, accessibility and a lightweight revision history. [docs/reference/legacy-implementation.md](../reference/legacy-implementation.md) now records the visual archaeology and Recover/Adapt/Reference only/Retire boundary as non-authoritative historical evidence. This status document remains the owner of implementation and verification evidence. No competing design-system document or architecture decision was created. ### Validation and remaining limitations Completed checks: read-only git status/tracking/history inspection; direct source inspection of the contaminated and package copies; confirmation that the target layout still links `/style.css`; confirmation that the tracked target stylesheet now starts at `:root`, contains no `Build Mode` or `post-PDO` text and has balanced braces; documentation authority and cross-reference review. The target CSS was not browser-rendered in this source-integrity change, and package copies were not regenerated. Existing application behavior tests were not rerun because this change did not alter runtime behavior; the existing 69/69 bounded IDY-010 HTTP evidence remains historical evidence from 2026-09-19, not new verification for this BUILD. **Next stage:** continue the Surface UI reconstruction beyond the admission and shell slice, then regenerate and verify release/package artifacts from the tracked source. Browser, accessibility, live HTTP and package evidence remain separate gates; the first implemented slice is recorded below. ## First Surface UI Reconstruction BUILD **Evidence date:** 2026-09-22 **Scope:** first visual implementation on the current target surface. Existing routes, admission fields, session behavior, Business context resolution, object projections and Command/Operation boundaries were preserved. Implemented in [target/style.css](../../target/style.css): a coherent target token layer, dark/teal branded shell surfaces, light workspace and admission composition, typography hierarchy, panels, controls, buttons, links, status badges, notices, focus states, responsive table behavior and reduced-motion handling. Implemented in [resources/views/target/layout.php](../../resources/views/target/layout.php), [login.php](../../resources/views/target/login.php), [register.php](../../resources/views/target/register.php) and [confirm.php](../../resources/views/target/confirm.php): branded admission framing, current Business context, capability-driven navigation, active route treatment, semantic section headings and supplied light/dark horizontal wordmarks served from `target/assets/idiosyncrasy/`. The two SVG files are registered in [release/target-release.json](../../release/target-release.json), so the target does not depend on sibling source assets at deployment time. No legacy marketing navigation or legacy authority behavior was restored. ### Validation - PHP 8.3.33 lint passed for all 15 files under `resources/views/target/`. - Focused stylesheet validation passed: no operational contamination, balanced braces, target layout reference intact, focus/reduced-motion rules present. - The supplied light and dark wordmarks were copied byte-for-byte into the target public boundary, referenced by the target layout with accessible alternative text, and listed in the authoritative target release definition. - The existing `bin/run-http-acceptance.ps1 -Suite idy010` validation was attempted and blocked before execution because MySQL at `127.0.0.1` was unreachable; no pass/fail assertions were produced. - No staging or production deployment occurred. Release/package artifacts were not regenerated. ### Deferred The final unified font choice, palette consolidation/contrast certification, exact breakpoint reconciliation, browser screenshots, assisted-technology verification, live target HTTP behavior and package regeneration remain unverified or deferred. This BUILD establishes the first implemented surface slice; it does not claim complete Surface UI reconstruction. ## Target Release Foundation Evidence ### Reviewed resolution correction The previous reviewed target resolution was **166 files**. The Capability Application handler, persisted projector, core-object Presentation provisioning and required Definition/Capability vocabulary add net files; the current exact public boundary is recorded by the release manifest, with exact-file-set and GitHub provenance validation. The corresponding internal provisioning package currently resolves to **200 files**. Historical file-count observations remain historical and are not rewritten. The reviewed target release definition is [release/target-release.json](../../release/target-release.json). It is authoritative for the current target boundary; the resolved file list is derived from its approved patterns and explicit path snapshot. The current checked-in source resolves to the release manifest's verified file count. It includes the persisted Definition Explorer/publication path, Business-derived Capability Application handler, persisted-state capability projector, server-side Operation source resolver, exact Operation-identity authorization, no-network `send_email` simulation, core-object Presentation provisioning, existing bounded target UI, initialization classes and verified public assets. Provisioning-only Genesis, publisher installation and platform-opening materials remain outside the public target release. The test-only recording adapter is under `tests/Support/` and is intentionally outside the target release. The internal `StagingProvisioningPackage` includes all runtime PHP and currently resolves to 202 files. The former `release-staging/` audit was retired and is no longer used as current release evidence. [TargetReleaseDefinition](../../app/Release/TargetReleaseDefinition.php) rejects unsafe, duplicate or link-based paths and requires pattern expansion to equal the reviewed snapshot. [TargetReleaseManifest](../../app/Release/TargetReleaseManifest.php) requires GitHub authority, repository, full commit SHA and non-secret build identity; those fields participate in the canonical manifest digest and derived release ID. [TargetReleasePackage](../../app/Release/TargetReleasePackage.php) creates only from an explicitly supplied source checkout and provenance file, and verifies an existing package without rebuilding it. Earlier focused package evidence used the 164-file public and 155-file internal sets (18 tests, 622 assertions; one test skipped). The prior public 166-file and internal 157-file package suites passed **18 tests / 630 assertions, one skipped**; those counts predate this release-boundary change. The current read-only target resolution check passed at 228 public files and 202 internal files with PHP syntax checks. The public GitHub upload step preserves hidden files so the already-authoritative `target/.htaccess` survives artifact archival. The historical staging comparison was retired with the snapshot; the current source boundary remains governed by the reviewed definition and exact-file-set checks. [bin/target-check.ps1](../../bin/target-check.ps1) is a read-only local release-definition check. [bin/target-local.ps1](../../bin/target-local.ps1) is a guarded local launcher using the separate `var/target-sessions-local` path and loopback-only local database configuration. [bin/target-release.ps1](../../bin/target-release.ps1) consumes an already-created GitHub-bound package and verifies the 228-file manifest and exact provenance before its existing operator-visible phases. It does not package the arbitrary local working tree. Production activation and post-activation HTTP evidence remain unverified. Normal releases remain code/assets only and do not run migrations, provisioning, Genesis, platform opening, database mutation, staging or Plesk changes. The ordinary release command is a code/asset operation only. It refuses migrations, provisioning, Genesis, platform opening, schema changes, data mutation, credential creation and Plesk configuration changes. It never includes or overwrites `var/target-sessions`. The explicit `bin/target-release.ps1 -UploadOnly` operator mode performs the same local package checks, release-specific staging-directory preparation and recursive SCP transfer, then exits successfully without remote verification or activation. It does not change package contents or touch persistent sessions, database state, migrations, provisioning, Genesis, platform opening, Plesk or document-root configuration. A successful upload is staging evidence only, not remote integrity verification or activation evidence. The explicit `bin/target-activate.ps1 -ReleaseId ` operator is implemented for an already-uploaded release. It validates the release-specific staging controls and structure, preserves the existing real `target` directory under a release-specific rollback location, switches `target` to the staged release's target pointer, and requires the activated identity plus HTTP `/register` check before success. Failure restores the previous target; the previous target is retained after success. Local PHP pointer resolution and PowerShell payload generation passed; a local POSIX shell execution and production activation remain unverified because no local WSL distribution is installed and production activation has not been run. The former `bin/target-upload-direct.ps1` file was obsolete historical material and has been removed. Only a GitHub-bound package consumed by `target-release.ps1` is eligible for the reviewed staging path. ### Stage 1 GitHub authority disposition | Requirement | Status | Evidence or remaining gate | | --- | --- | --- | | GitHub repository and exact commit in release metadata | IMPLEMENTED / VERIFIED LOCALLY | `TargetReleaseProvenance`, canonical manifest, and package round trip; no credentials are stored. | | Reproducible package from exact checkout | IMPLEMENTED / VERIFIED LOCALLY | `.github/workflows/build-target-release.yml` checks out `${{ github.sha }}`, validates, builds and uploads a verifiable artifact; the dependent staging job downloads that exact same-run artifact. | | Local operator cannot treat arbitrary working tree as release source | IMPLEMENTED / VERIFIED LOCALLY | `target-release.ps1` requires an existing provenance-bearing package; `target-package.php` separates `--create` and `--verify`. | | Direct local-to-live upload | RETIRED | The obsolete direct-upload path was removed; only GitHub-bound packages are eligible for release handling. | | Remote provenance and package verification | REQUIRES REMOTE VERIFICATION | SSH capability is unresolved; no production command was run. | | Production deployment/activation | NOT YET IMPLEMENTED FOR THIS STAGE | No upload, activation, database mutation, migration, environment or Plesk change occurred. | ### Staging deployment capability The repository now has an explicit staging provisioning contract without changing the 133-file public runtime boundary. `bin/provision-target.php --database=staging` requires `IDY_STAGING_DB_NAME`, verifies that it matches `IDY_TARGET_DB_NAME`, rejects `idio2plat` and production-looking identities, and records migrations as `IDY-STAGING`. `--database=target` retains the exact `idio2plat` production safeguard and its existing release identity. The automatic staging application deployment path is implemented in `.github/workflows/build-target-release.yml`: a successful push to `main` completes `build-target-release`, then the protected `deploy-staging` job downloads the exact same-run target release and calls `bin/staging-deploy.sh`. The helper validates the target artifact, establishes the existing password-authenticated SSH connection, uploads and installs the unchanged application package, and performs one GET request to `STAGING_URL/health`. GitHub receives no staging database credentials and performs no staging reset, migration, Genesis, platform opening or provisioning. Those operations are internal-script-only and must be explicitly authorized outside GitHub Actions. The workflow has no production reset or provisioning path. The private staging provisioning package remains an internal operator artifact containing target runtime dependencies, the shared migration CLI, provisioning material, runtime migrations, the staging-only reset command and the required Genesis/platform-opening manifests. It contains no credentials and is never intended for the public document root or GitHub deployment. Staging migration and provisioning must be run by the internal scripts when explicitly authorized. Focused PHPUnit verification runs through the supported local wrapper; any remaining test deprecations are recorded in task evidence. The selected-database preflight correction is IMPLEMENTED / VERIFIED LOCALLY: `TargetProvisioningPreflight::assertEmptyDatabase()` now binds its schema query to the validated `TargetRuntimeConfig` database identity. Production retains the exact `idio2plat` selector boundary; staging retains the explicit `IDY_STAGING_DB_NAME` equality and production-looking-name rejection. The focused `TargetProvisioningPreflightTest`, `StagingDatabaseResetterTest` and `StagingProvisioningPackageTest` run through the pinned local wrapper with 17 tests and 59 assertions passing; two PHPUnit deprecations remain. The staging reset contract is IMPLEMENTED / INTERNAL-SCRIPT-ONLY / NOT EXECUTED: `bin/reset-staging-database.php --database=staging` requires explicit staging context and confirmation, matching target/designated staging identities, a non-production identity, and a same-server `IDY_STAGING_RESET_DB_*` administrative capability. Under the agreed single-user staging model, `IDY_STAGING_RESET_DB_USER` may equal `IDY_TARGET_DB_USER`; the dedicated reset capability settings and password remain explicit, and host/port must match the configured staging database server. Internal scripting must invoke reset before `provision-target.php --database=staging`; reset failure prevents provisioning. The disposable staging provisioning harness independently passed with 14 migrations, one Genesis run, one applied platform opening and zero credentials, using a generated local database which it cleaned up. The disposable reset end-to-end rehearsal remains **UNVERIFIED** because its prior permitted execution evidence was incomplete; no reset rehearsal or deployment was run for this integration task. Reset capability settings are not supplied through the GitHub deployment workflow. No staging reset or deployment is evidenced by this implementation. **Implemented / locally verified:** staging identity validation, production identity rejection, 131-file public boundary preservation, internal staging bundle creation and provenance verification, the ledger-backed internal staging migration invocation, the application-only workflow/helper contract, the `sshpass` password-authentication contract, PHP lint, the focused 17-test/59-assertion suite, and the disposable staging provisioning rehearsal. The rehearsal completed with 14 migrations, one Genesis run, one applied platform opening, zero credentials, and successful disposable-database cleanup. **Not verified:** the disposable reset end-to-end phase sequence because its permitted execution evidence was truncated/incomplete; transfer to the real staging host, SSH authorization, staging filesystem permissions, DNS/TLS/PHP-FPM configuration, `/health` behavior on the host, or any real automatic staging deployment. The current workspace had no staging connection inputs or `sshpass`, and its cached package carried local zero-SHA provenance, so no live deployment was claimed or attempted. Shell syntax validation remains unavailable because this Windows environment has no installed WSL distribution. ### Direct staging deployment status The current Development Staging v1 mechanism is intentionally limited to exact artifact upload, package-tree installation under `STAGING_REMOTE_ROOT`, and one GET request to `STAGING_URL/health`. The deleted capability probe, activation lock, symlink switch, rollback choreography and remote manifest reconstruction are not part of this path. The 2026-09-21 live deployment request was blocked before remote execution because the workspace did not contain the staging GitHub Environment inputs, `sshpass` was unavailable, and the cached package was not bound to a real commit. **Not verified:** the disposable reset end-to-end phase sequence, a real automatic staging deployment, SSH authorization, remote filesystem permissions, DNS/TLS/PHP-FPM configuration, or the staging `/health` response. ## Status Vocabulary | Label | Meaning | | --- | --- | | SETTLED | Semantic contract approved in final D01-D10; not evidence of code | | SPECIFIED | A concrete implementation mechanism is chosen under that contract; not a new architecture decision or implemented feature | | NOT BUILT | No compliant implementation is evidenced in this inventory; existing unrelated functionality is not partial credit | | PARTIAL | A named part of the new contract has implementation evidence, with the uncovered parts stated | | VERIFIED | A specific requirement passed a recorded check against an identified revision/environment; not a blanket system claim | | OBSERVED | Source indicates behavior or an earlier snapshot describes it; not execution verification | | READY FOR CLOSURE | The audited implementation satisfies the frozen contract, with any remaining verification limitation recorded separately | | ENVIRONMENT BLOCKED | An executable verification could not run because of an environment prerequisite; this is not a test pass or implementation failure | No row below is promoted to VERIFIED merely because this documentation was linted or linked successfully. Future evidence records must identify requirement, canonical owner, code/revision, check/fixture, date/environment, result and remaining limits. ## IDY-001 Repository Isolation Evidence **Requirement:** establish a distinct target runtime boundary without connecting it to the legacy application or database. **Implementation evidence:** - Target entrypoint: [target/index.php](../../target/index.php), with target-local [rewrite rules](../../target/.htaccess). - Target configuration boundary: [TargetRuntimeConfig](../../app/Runtime/Bootstrap/TargetRuntimeConfig.php) accepts only `IDY_TARGET_DB_*` settings, requires target host/name/user values, and rejects a target database name equal to legacy `DB_NAME` or `LEGACY_DB_NAME` when supplied. - Target route boundary: [TargetRuntimeBoundary](../../app/Runtime/Bootstrap/TargetRuntimeBoundary.php) exposes only non-mutating `GET /` and `GET /health`; it does not load the legacy Router, database singleton, controllers or session bootstrap. - Legacy boundary: the former root entrypoint and hosting boundary have been removed. The target is the remaining application runtime and retains its separate document root/deployment and database contract. - Deterministic check: [bin/check_idy001.php](../../bin/check_idy001.php) covers missing-target fallback refusal, target/legacy database-name collision refusal, target health resolution, legacy mutation-route rejection and legacy-route preservation. **Evidence recorded 2026-09-13:** the pinned PHP smoke task reported PHP 8.3.33, and the focused [IDY-001 checker](../../bin/check_idy001.php) completed all seven isolation, boundary and legacy-route checks. A live loopback HTTP verification then started the pinned PHP 8.3.33 built-in server with `target` as its document root and `target/index.php` as its router at `http://127.0.0.1:8081`, using only the existing isolated local database configuration mapped to `IDY_TARGET_DB_*`. `GET /health` returned HTTP 200 with `{"runtime":"target","status":"boundary_ready","database_configured":true,"database_connected":true,"mutation_routes":[]}`. `GET /` returned the same HTTP 200 target response. `POST /campaigns` returned HTTP 404 with `{"runtime":"target","error":"route_not_found"}`. The GET responses included `Content-Type: application/json; charset=utf-8`, `Cache-Control: no-store` and `X-Content-Type-Options: nosniff`. The server log showed normal request handling with no application error, and the temporary server was stopped with port 8081 released. Because the target composition root creates PDO before dispatch, `database_connected:true` is live evidence that the target database-backed path was exercised through HTTP; the configured database was the isolated `idiosyncrasy_dev` database. No setup script, migration, session or external service was accessed. **Status:** VERIFIED for the IDY-001 target boundary under the stated local environment. This verifies the real target entry point, target-only configuration boundary, live PDO connection and rejection of the legacy mutation route through HTTP; it does not verify production Apache/PHP-FPM ingress, deployment configuration or broader application behavior. **Finding:** the legacy `smartftp.json` deployment-credential file contains deployment credentials and is not part of the target runtime. It remains a legacy/deployment security risk requiring separate credential rotation and source-control handling; IDY-001 did not upload, reuse or expose it. The file is not present in the current tracked workspace, so this note is retained as historical security context rather than a live file link. ## Local Development Environment Evidence **Requirement:** prepare a reproducible local runtime/database combination compatible with the chosen first-milestone production baseline, without creating IDY-002 application behavior or running legacy setup. **Environment recorded 2026-09-13:** Windows 10 Pro (64-bit, build 26200) with PowerShell 5.1. WSL 2.6.3 is installed, but no Linux distribution is present; the native user-local setup is therefore the smallest compatible mechanism. No pre-existing `php`, MariaDB, MySQL, database service, database listener or PHP 8.4 executable was found on PATH or in the inspected common installation locations. No global PATH, Windows service, Composer, framework, application code, database schema or legacy setup script was changed. **Provisioned runtime:** PHP 8.3.33 NTS Visual C++ 2019 x64 and MariaDB 10.5.26 Windows x64 are installed below `%LOCALAPPDATA%\Idiosyncrasy\dev-runtime`, outside the repository. MariaDB's vendor-published SHA-256 for its ZIP was checked before extraction. The server is loopback-only at `127.0.0.1:3306`, uses `utf8mb4`/`utf8mb4_unicode_ci`, defaults to InnoDB and has `innodb_file_per_table=ON`. An isolated empty `idiosyncrasy_dev` database and a database-scoped non-root user are configured with credentials stored only in the local ACL-restricted configuration directory. **Checks passed:** the PHP CLI reports `PHP 8.3.33`; `PDO`, `pdo_mysql`, OpenSSL, cURL, DOM and Fileinfo are loaded. The database reports `10.5.26-MariaDB`, `mariadb.org binary distribution`, default `InnoDB`, `utf8mb4` and `utf8mb4_unicode_ci`. The non-root client created and dropped an InnoDB probe table, leaving zero tables. The pinned PHP executable connected to the isolated database using a `mysql:` PDO DSN and reported `PDO_OK:10.5.26-MariaDB` with the `mysql` PDO driver present. The generated MariaDB root client defaults file was restored in the local configuration directory after the database test reported it missing. **Operational interface:** [bin/php83.ps1](../../bin/php83.ps1) remains the pinned-PHP wrapper for direct use. The test and HTTP acceptance runners, and the PHP-specific [VS Code tasks](../../.vscode/tasks.json), invoke the same pinned executable directly because the machine's `powershell.exe -File bin/php83.ps1` bridge is unreliable. [bin/dev-db.ps1](../../bin/dev-db.ps1) supports `Start`, `Stop`, `Status` and `Test`; the latter verifies client and PHP PDO access without printing credentials. Static diagnostics passed for these helpers and tasks. This is a native Windows compatibility environment, not a substitute for later Linux/PHP-FPM or Plesk ingress verification. **Status:** VERIFIED for the stated local PHP/MariaDB/PDO/InnoDB compatibility prerequisites. No IDY-002 or other new-platform application/runtime requirement is promoted by this environment evidence. ## Production Target HTTP Boundary Evidence **Requirement:** verify the deployed target HTTP boundary after the successful post-PDO startup trace, without provisioning, migration, Genesis, opening, database mutation or application changes. **Evidence recorded 2026-09-19:** read-only GET requests were sent to `https://platform.idiosyncrasy.co.uk` through the live Plesk ingress. `/health` and `/` each returned HTTP 200 with `runtime=target`, `status=boundary_ready`, `database_configured=true`, `database_connected=true` and `mutation_routes=[]`. `/login` and `/register` each returned HTTP 200 with a JSON CSRF bootstrap response. An unknown route returned HTTP 404 with `{"runtime":"target","error":"route_not_found"}`. The responses identified `PHP/8.3.33,PleskLin` and included `Content-Type: application/json; charset=utf-8`, `Cache-Control: no-store` on the boundary responses and `X-Content-Type-Options: nosniff`. This validation exercised the deployed target entrypoint and dispatch boundary only. It used no POST request, provisioning command, migration, Genesis, platform opening, database inspection or database mutation. The Plesk system logs remain inaccessible to the deployment account (`Permission denied`), so this evidence verifies current behavior but does not identify the historical `target_configuration_unavailable` exception. `runtime_coordination` remains neither observed nor established as that historical cause. **Status:** VERIFIED for the current live target HTTP boundary under the stated production URL and date. This is limited to the observed GET boundary, startup/composition readiness and route response contract; it does not verify the complete first-milestone lifecycle, privileged PHP-FPM/Plesk log access, backups or production provisioning state. ### Production HTTP/runtime release deployment **Evidence recorded 2026-09-19:** the audited local `release-staging/` release was transferred by non-destructive SCP into the existing application root `/var/www/vhosts/idiosyncrasy.co.uk/platform.idiosyncrasy.co.uk/`. The transfer contained exactly 128 files: 111 `app/Runtime` PHP files, 13 target templates, 3 target public files and 1 bootstrap file. No `var/`, database, CLI, test, documentation, configuration or deployment files were transferred, and the Plesk document root remained `target/`. Read-only remote verification found all 128 expected files, all four critical paths, and `var/target-sessions/` present. SHA-256 values for the transferred files matched the audited local release inventory. The session directory was outside the transfer scope and was not replaced or targeted. No provisioning, migration, Genesis, platform opening, database, environment, PHP or Plesk operation was performed. The post-transfer HTTP smoke test used GET requests only. `/` returned HTTP 303 redirecting to `/login`; `/login` with `Accept: text/html` returned HTTP 200 HTML without `target_configuration_unavailable`; and `/health` returned HTTP 200 with `boundary_ready`. HTTP verification was observed at 13:27:39 GMT on 2026-09-19. **Status:** VERIFIED for the audited HTTP/runtime file transfer, remote file checks and bounded GET smoke test. This does not certify the complete application lifecycle, backup/restore state or broader production security posture. The earlier preflight evidence below records the state before this deployment and should not be read as a current claim that no production files were ever modified. This provisioning-preflight investigation did not initiate a production database connection. No provisioning command, migration, Genesis operation, platform-opening operation, or other production database mutation was executed. `provision-target.php = BLOCKED` ### Temporary staging registration diagnostic **Status: EXECUTED / ROOT CAUSE IDENTIFIED; CORRECTIVE DEPLOYMENT PENDING.** The standalone [staging registration diagnostic workflow](../../.github/workflows/staging-registration-diagnostic.yml) uses the existing `staging` GitHub Environment, builds and verifies the selected exact-commit 159-file target release on the runner, and performs bounded read-only SSH, HTTP GET and database metadata inspection. Its [remote helper](../../bin/staging-registration-diagnostic-remote.sh) is streamed over SSH stdin and does not create persistent staging files. The diagnostic does not deploy, upload, install, migrate, provision, submit POST requests, mutate staging database rows or filesystem state, change Plesk/web-server configuration, or access production. Its bounded metadata inspection reports the POST-only schema tables and `command_keys.business_id` nullability, `CREDENTIALS_COUNT`, `GENESIS_RUNS_COUNT`, and, when present, each credential's `principal_id`, derived `status`, `created_at`, `updated_at`, `password_changed_at`, and `disabled_at`. It excludes password hashes, normalized login identifiers, challenge data, tokens, and all other credential material. The inspection also reports migration-ledger state, `principal.register`/`principal.confirm` Operation metadata, platform-opening records, current database privileges, and bounded error-log evidence. On the staging run for commit `0d8c9c2744eccea2bccb44d2d6074fb29cbc7e46`, the deployed target identity and 131-file boundary matched the expected commit/package checks, `/register` GET returned 200 with target markers, all admission tables and required privileges were present, migration `0012`/`0013` were present, and the opening ledger reported one `APPLIED` record. Both canonical admission Operations were absent. This established opening/Operation drift as the registration failure; the registration handler and schema were not the defect. The expected/deployed target release ID and digest difference is not causal evidence of source divergence: the target manifest identity includes the GitHub build provenance, including the per-run build identity, so separate workflow runs for the same commit can produce different content-derived release identities. The diagnostic distinguishes this artifact identity from the exact commit identity. The corrective code now reconciles approved opening effects whenever a matching `APPLIED` ledger row exists, and the normal staging migration step invokes that reconciliation before installing the public package. Staging deployment and the disposable end-to-end registration/confirmation/authentication/`business.create` validation remain **PENDING** until the corrected commit is pushed through the existing staging workflow; registration is not yet marked fixed. The existing manual diagnostic now also streams a CLI-only bootstrap probe through its authorized SSH connection. The probe source is required in the checked-out workflow revision and is base64-streamed in the SSH command environment; the remote helper explicitly reports unavailable transport instead of silently omitting the probe. The probe runs against the already-installed staging root, requires no target-package upload and is not persisted on staging. It invokes the real `TargetRuntimeCompositionRoot::fromEnvironment()` path using the installed release's autoloader and process environment, then emits bounded exception evidence: class, sanitized message, code, application-relative file, line and at most 12 stack frames. Output is limited to structured fields; trace arguments and probe stderr are not emitted, and password, credential, token, cookie, session and DSN-like values are redacted or omitted. A thrown composition root returns a nonzero probe result while a completed composition root returns success. The probe does not change target HTTP behavior, add persistent logging, or add migrations/provisioning/database operations; it intentionally preserves any existing startup behavior performed by the real composition root. It is staging/operator-only and is invoked only when the [staging registration diagnostic workflow](../../.github/workflows/staging-registration-diagnostic.yml) is manually dispatched; this implementation has not itself been executed against staging. ## New-Platform Verification ### Definition-Driven Principal and Business Initialization Slice **Status: IMPLEMENTED / FOCUSED-VERIFIED, 2026-09-23.** The target runtime now installs platform-owned, revisioned Principal and Business Definition objects and a generic constituent object Type through the existing universal object/revision model. It creates Business-scoped initialization Workflow Definition/Node and Operation objects on demand, binds a Workflow Execution to the existing subject and exact Definition/Workflow revisions, projects requirements generically through JSON/HTML target boundaries, and routes explicit input through OperationInvocationService and CommandHandler. Initialization uses deterministic constituent identities, recognizes compatible existing constituents, rejects ambiguous/incompatible constituents, and finalizes only when required Definition requirements are satisfied. Credentials, confirmation material and session data remain outside generic constituents. ### Presentation-Driven Generic Object Explorer **Status: ARCHITECTURE REFACTORED, 2026-10-04.** The `/objects/{id}` endpoint is now the canonical generic object exploration endpoint, with Business-scoped Presentation Definitions determining visibility and no automatic relationship discovery. A Presentation Instance is optional: it records a binding when explicit presentation-specific state or an independently addressable presentation binding is required; ordinary objects render directly from their Business Presentation Definition. Presentation Instances do not become copied sources of business data. The rendering flow follows: object resolution → optional Presentation Instance binding resolution → Business Presentation Definition resolution → presentation projection (using detail_fields) → generic presentation rendering → HTML. Object references render as links back to `/objects/{id}`, primitives as `Name: value`, and collections as linked object lists. The crucial separation is: data graph (all relationships as they exist) versus presentation (which relationships are explicitly exposed by the Presentation Definition). Future Standard Presentation Definitions and Business-derived definitions remain an architectural seam, not a current implementation claim. **Changes:** - Removed automatic relationship/composition discovery from object_detail.php - Removed template-driven logic enumerating database relationships - Kept object_detail.php as thin rendering layer only - All visibility decisions driven by presentation definition - Established principle: nothing becomes visible merely because it exists in the data graph **Architecture:** - TargetHtmlBoundary::objectDetail() resolves object, fetches presentation definition, projects using detail_fields only - object_detail.php renders three modes: primitives, object references (as links), collections - No automatic traversal; every navigable reference must be explicit in presentation - Object references link to canonical `/objects/{id}` with view_id context **Implementation status:** - [x] Refactored object_detail.php to presentation-driven rendering - [x] Removed automatic relationship enumeration from template - [x] Fixed TraversalEngine and GenericRenderer instantiation in composition root - [x] Created PRESENTATION-DRIVEN-OBJECT-EXPLORER.md documentation - [ ] End-to-end testing of recursive navigation - [ ] Alignment of GenericObjectsExplorer with presentation-driven semantics - [ ] Navigation test suite for object references Focused evidence: [DefinitionDrivenInitializationTest](../../tests/Integration/DefinitionDrivenInitializationTest.php) passed **3 tests / 19 assertions**. The existing [PrincipalAdmissionBusinessCreationTest](../../tests/Integration/PrincipalAdmissionBusinessCreationTest.php) regression passed **7 tests / 135 assertions**. [ExistingSpearmintInitializationTest](../../tests/Integration/ExistingSpearmintInitializationTest.php) resolves the named Business by durable identity and never creates/deletes/replaces it, but its local-snapshot result is not promoted to VERIFIED: one refreshed snapshot explicitly lacked an eligible local Spearmint membership and another run was blocked by the pre-existing Genesis/ledger fixture error. No database migration or staging deployment was performed. The broader workflow/configuration command was not promoted to a pass because existing `Idy007AVocabularyTest` and related workflow suites fail during fixture cleanup with pre-existing foreign-key/Genesis-store errors before their relevant assertions. This slice does not implement definition adoption or automatic migration, general recursive derived-state propagation, universal relationship recovery, general deletion lifecycle, unresolved-dependency resolution workflows, cycle pause/review, broad Policy composition or AI-assisted configuration. Workflow execution state is reused for initialization progress; `initialized` means only that this execution's declared requirements were satisfied. ### Object Presentation Current Evidence **Status: DOCUMENTED ARCHITECTURE / AUDIT ONLY; NO CONSOLIDATION BUILD AUTHORIZED, 2026-10-05.** See the [canonical Object Presentation contract](../architecture/core-object-model-and-authority.md#object-presentation-in-the-core-object-model) and the [View/UI implementation route](../architecture/views-and-content.md#object-presentation-routing). Current evidence is limited to the ordinary-object explorer path, capability projection paths and their existing renderer compositions. These paths remain separate implementations; their common model and duplication are not yet verified. No templates, projectors, routing branches, database objects or presentation configuration were changed in this audit. Consolidation remains unauthorized until legitimate composition differences and accidental duplication are separately classified. ### Core Object Model and Platform Authority Reconciliation **Status: DOCUMENTATION RECONCILIATION ONLY / NOT RUNTIME-VERIFIED, 2026-09-23.** The cross-cutting [core object model and authority](../architecture/core-object-model-and-authority.md) document and its owner cross-references now record the following obligations. This alignment does not promote any item to `VERIFIED`, change release scope or claim a complete universal runtime. The semantic contracts are settled, but specified does not mean implemented or proven. The following remain explicit deferred implementation capabilities: definition adoption and instance evolution; recursive derived-State calculation, invalidation/materialization and propagation; universal relationship endpoint-loss resolution and relationship lifecycle; general ordinary-removal, retirement and destruction behavior; runtime unresolved-dependency Events and resolution workflows; static/runtime cycle detection, pause and authorized review; broad Policy composition/conflict evaluation; provider-independent AI proposal validation and execution; and richer causal-history reconstruction beyond the bounded evidence slices named below. | Obligation | Current evidence boundary | |---|---| | Empty and definition-less objects; arbitrary constituents; definitions as descriptive objects | Generic object/configuration slices exist, but complete arbitrary object and definition lifecycle coverage is not verified. | | Actual graph versus intended definition; explicit, revisioned definition adoption without automatic instance migration | IDY-008 installation is bounded configuration work; definition adoption and instance migration are not evidenced as a runtime capability. | | Derived State and recursive propagation through constituents and relationships | Addressable State definitions and bounded transition history are evidenced; general derived-state calculation, materialization and propagation are not verified. | | Multi-endpoint relationships and unresolved endpoint retention | Bounded relationship creation, integrity, cardinality and traversal are verified; universal endpoint-loss resolution and relationship retirement/deletion remain outside the verified slice. | | Ordinary data removal versus explicit retirement/destruction with retained history | The architecture specifies the distinction; the demonstrator's broader deletion, retirement and destruction behavior is not generally verified. | | Dependency classes, non-fabrication and unresolved-dependency events/resolution | Bounded workflow dependency references and execution controls exist; the full resolved/absent/unresolved/incompatible/failure behavior is not verified. | | Cycle detection, pause/escalation and finite workflow execution | The bounded interpreter limit is specified and partial workflow execution is evidenced; general causal cycle detection and human-resolution behavior are not verified. | | Author, relationship, ownership and AI output do not grant authority; human-only parity | Admission, Business isolation and selected AI-negative contracts are evidenced; broad authority coverage across all object/configuration categories remains incomplete. | The implementation mechanism may materialize derived state, use relationship indexes, retain revisions or enforce a finite dispatcher bound, but those mechanisms remain subordinate to durable object state and the settled semantic contracts. See [implementation architecture](architecture.md), [development](development.md) and the relevant architecture owners for chosen mechanisms and required checks. ### Platform Governance Foundation **Status: PARTIAL / FOCUSED ADMISSION LIFECYCLE VERIFIED.** Implemented evidence includes the explicit `platform`/`business` scope value object, direct-Principal platform AuthorityGrant lookup, exact platform Policy lookup with fail-closed conflict handling, scope-aware Command fingerprint inputs, the release-configured trusted `business.create` handler, composition-root registration and migration `0010_platform_governance_scope` for nullable platform Command/Event Business scope. The single CommandHandler admits and atomically commits the bounded platform bootstrap; the platform evidence descriptor revision permits nullable platform Command/Event Business scope without weakening the frozen IDY-005 artifact. The historical PHPUnit collection block caused by the unavailable `mbstring` extension has been cleared for the focused Foundation Genesis runner by loading the existing extension through the pinned PHP executable. ### Principal Admission to Initial Business Evidence **Executable verification status: VERIFIED for the bounded admission lifecycle slice; broader security and deployment coverage remains incomplete.** `principal.register` and `principal.confirm` are active revision `1` Operations with trusted handlers. `PrincipalAdmissionService` registers a pending Principal with normalized identity, Argon2id credentials and a hashed one-time confirmation challenge; confirmation activates the Principal and issues the platform onboarding grant. The target boundary routes registration, confirmation and platform commands through the existing governed Command path. `CommandHandler::handleAdmission()` resolves the exact Operation, validates the trusted handler, creates durable Command, Attempt, Outcome, Event and Provenance evidence, invokes the transaction-participating admission service, and owns the outer transaction. The focused integration test uses the actual `TargetRuntimeCompositionRoot`, Foundation-only Genesis, the platform governance/evidence vocabulary installers and isolated MariaDB state. The canonical run on the pinned PHP 8.3.33 runtime with PHPUnit 11.5.56 was `bin/run-tests.ps1 tests/Integration/PrincipalAdmissionBusinessCreationTest.php`: **2 tests, 42 assertions, 0 failures, 0 errors**, exit code 0. It verifies registration state and credential hashing, normalized login after confirmation, confirmation replay denial, invalid password denial, revocation of onboarding authority, server-owned initial Business/Membership/AuthorityGrant/Policy identities, settled Command/evidence linkage, command replay idempotency, payload conflict rejection and forged security-field rejection. PHP lint passed for the touched production and test files. Genesis foundation and re-run validation remain credential-empty: a fresh Genesis run refuses a populated credential store, and an attempted Genesis re-run after admission remains rejected. Genesis revision 1 and its manifest value remain the immutable foundation anchor, while later retained revisions of the same addressable definition object are permitted during runtime evolution and reconstruction. Runtime `GenesisRunner::assertCurrent()` validates that anchor rather than requiring every current seed revision to remain version 1, and it tolerates legitimate post-Genesis admission credentials. Focused regression coverage verifies credential tolerance, governance descriptor evolution and Genesis-anchor protection. Hardening evidence was recorded separately through `bin/run-tests.ps1 tests/Integration/PrincipalAdmissionHardeningTest.php`: **4 tests, 40 assertions, 0 failures, 0 errors**, exit code 0. It verifies expired challenges remain pending and cannot issue onboarding authority, two concurrent confirmation processes produce exactly one successful consumer and one onboarding grant, registration/confirmation failure leaves no partial admission state, and a deliberately failed platform Business bootstrap rolls back the Command/evidence admission and all Business-scoped effects. The platform Command admission and Business effects now share one transaction; the existing Command mutation boundary is unchanged. This evidence covers the JSON admission boundary and the normal governed `business.create` path. Target HTML registration and confirmation remain outside this slice; the bounded zero-Business onboarding view is covered below. No full-suite or production security certification is claimed. ### Zero-Business HTML onboarding **Status: VERIFIED for the bounded zero-Business HTML onboarding slice.** An authenticated Principal with no active Business membership now receives a first-use `Create a Business` form from `/businesses`. The form accepts only `display_name` and CSRF input. Its server-side HTML boundary generates the platform `business.create` Command envelope and invokes the existing `CommandHandler` with a null Business context, preserving active Operation, onboarding AuthorityGrant, platform Policy, trusted handler, idempotency, settlement, evidence and provenance checks. Browser input cannot supply Principal, Business, Membership, AuthorityGrant, Policy or Operation identity. After settlement, the HTML boundary reads the resulting Business identity from durable settled Command evidence, validates the authenticated Principal's active Membership through `BusinessContextResolver`, and only then establishes the session Business context and redirects to `/`. Missing or non-settled evidence fails closed. Existing one-Business and multiple-Business selection remains on the `/businesses` and `/business-context` path. Focused verification on the pinned PHP 8.3.33/PHPUnit 11.5.56 runner passed `PrincipalAdmissionBusinessCreationTest.php` with **5 tests, 75 assertions, 0 failures, 0 errors, 0 warnings and 0 skips**. Coverage includes the zero-membership form, invalid input, CSRF rejection, forged security fields, successful server-resolved context handoff, revoked onboarding authority, and the existing governed replay/conflict and forged-Principal boundary. The existing `Idy004AccessTest.php` selection suite was retried twice but its fixture failed during `CurrentLifecycleFixture` registration before reaching selection assertions; it remains an unrelated pre-existing test-environment blocker and is not claimed as passed here. The reported **41 editor problems** on `PrincipalAdmissionBusinessCreationTest.php` are all dependency/editor diagnostics: one unresolved `PHPUnit\Framework\TestCase` type and 40 inherited PHPUnit assertion-method warnings. They are false positives from the editor not indexing the repository's PHPUnit PHAR/autoload surface; the pinned runner executes the test successfully. The workspace-wide diagnostic scan also reports unrelated PHPUnit warnings in other test files and is not evidence of admission defects. No diagnostics were suppressed. The IDY-004 fixture now uses [CurrentLifecycleFixture](../../tests/Support/CurrentLifecycleFixture.php): after foundation-only IDY-003 Genesis and platform vocabulary installation, it admits Principals through registration, confirmation, login and governed `business.create`, resolving server-generated Business identity from persisted evidence. This is test infrastructure only; it does not add production provisioning, broaden `business.create`, restore historical Genesis state or create a generic test administrator. The focused IDY-004 run on PHP 8.3.33/PHPUnit 11.5.56 reached **14 tests and 87 assertions**, with **0 failures, 0 errors and 0 warnings**, and **1 explicit skip** for the deferred Policy activation/deactivation lifecycle. The supported inspection assertion now verifies the server-created Business through the existing governed `/businesses` identity projection, asserting its generated ID and display name; it does not treat an empty Business-Type `/objects` list as Business identity inspection. The history/revision and bounded object-listing fixtures now create target objects through authenticated Commands, using separate active Business-scoped mutation and inspection AuthorityGrants plus active allow Policies for the fixture Type. The Business root remains platform-scoped with `business_id = null`, while `/objects` remains limited to selected-Business-scoped objects. The malformed Principal rate-limit contract is resolved: after CSRF validation, malformed input receives source-address accounting without creating, accessing or mutating an identity bucket; canonical unknown UUIDs retain identity plus source accounting, and valid-but-unconfirmed noncanonical identities retain source-only accounting. No production authorization or mutation architecture changed. The hardening suite does not claim broader authentication/security certification, production concurrency behavior beyond the two-process InnoDB fixture, or deployment-level rollback guarantees. Rows below that are not covered by the bounded evidence record remain NOT BUILT in the sense defined above. Their semantic contracts are SETTLED and initial mechanisms are SPECIFIED in [implementation architecture](architecture.md). No architecture decision is reopened by missing code or tests. The existing code is not evidence of a generic object runtime merely because it persists campaigns, JSON payloads or activity rows. ### Runtime migration release correction The canonical fresh-release migration set contains 15 unique IDs in lexical order: `0013_platform_opening.sql` remains the canonical platform-opening migration, followed by `0014_retryable_confirmation_challenges.sql`. The retryable migration SQL is unchanged; only its fresh-release identity changed. Existing databases may contain the historical `0013_retryable_confirmation_challenges` ledger ID because that migration was previously applied under the colliding identity. `MigrationRunner` validates that legacy row against the unchanged retryable SQL checksum and treats it as satisfying canonical `0014` without executing the SQL again; it does not rewrite, delete or mutate the legacy ledger row. Invalid legacy checksums fail closed. Fresh databases execute and record canonical `0014` once, while platform-only databases execute it once and subsequent runs remain empty. `0013_platform_opening` remains unchanged and canonical. No production database or Plesk configuration was modified. ### Target provisioning and platform opening The CLI-only [target provisioning command](../../bin/provision-target.php) has explicit `--database=target` and `--database=staging` selectors. Production `target` reads only `IDY_TARGET_DB_*`, requires the fixed target database identity `idio2plat`, and preserves the exact production safeguard. Staging additionally requires `IDY_STAGING_DB_NAME` to equal `IDY_TARGET_DB_NAME` and rejects production-looking identities. Both selectors verify the selected PDO database and refuse any existing table before mutation. They sequence reusable migrations, foundation-only Genesis and the approved Operation/Governance prerequisites without changing HTTP startup, normal Principal-bound authorization or human state. The release-bound [platform opening applicator](../../app/Runtime/Configuration/PlatformOpeningApplicator.php) validates the release, derived Genesis digest and immutable [effect mapping](../../database/genesis/idy-platform-opening-effects.json), applies the `principal.register`, `principal.confirm` and `business.create` Operations plus the platform Policy, and records identity, artifact, Genesis, mapping, effect and technical provenance evidence in the dedicated `platform_opening_applications` ledger. It uses no Principal, Business, Membership, credential, AuthorityGrant or persistent technical actor. #### Approved opening contract The opening release applies three Operations and one Policy. The persisted admission Operations are: | Operation | ID | Revision | Scope | Handler | Status | | --- | --- | --- | --- | --- | --- | | `principal.register` | `9f4f6b8c-3d2e-4f10-8a11-223344556698` | `1` | `platform` | `platform.principal-register` | `active` | | `principal.confirm` | `9f4f6b8c-3d2e-4f10-8a11-223344556699` | `1` | `platform` | `platform.principal-confirm` | `active` | The persisted `business.create` Operation is: | Field | Approved value | | --- | --- | | ID | `9f4f6b8c-3d2e-4f10-8a11-223344556697` | | Name / revision | `business.create` / `1` | | Scope | `platform` | | Operation Type / revision | `9b4f6b8c-3d2e-4f10-8a11-223344556696` / `1` | | Handler | `platform.business-create` | | Inputs | `display_name`: string, required | | Targets | `{}` | | Context | `principal_id`: string, required | | Dependencies | `[]` | | Status | `active` | The persisted platform Policy is: | Field | Approved value | | --- | --- | | ID / name / revision | `7f3c2a91-6d84-4b27-9e53-c1a7f8402d6b` / `platform_business_create` / `1` | | Policy Type / revision | `bc1a466c-cc5f-4674-bd75-97281471a16b` / `2` | | Scope / Business | `platform` / `null` | | Status / effect | `active` / `allow` | | Operations | `business.create` | The immutable checked-in mapping is [idy-platform-opening-effects.json](../../database/genesis/idy-platform-opening-effects.json): identity `idy-platform-opening-effects`, version `1`, canonicalisation `json-object-keys-recursive-v1`, SHA-256 `3f47a5e29e5704b9d85696ec31259d6b7e3e4a4706f9cc3cd6ea7eaed171ef43`, release `IDY-PLATFORM-OPENING`. The digest is pinned to the canonical checked-in artifact and is not generated at provisioning time. Its effects are: verify opening artifact/digest; verify Genesis digest/run; verify Operation Type; verify Policy Type; assert all three trusted handlers/contracts; apply the `principal.register`, `principal.confirm` and `business.create` Operations; apply the platform Policy; and apply opening evidence. The Operation, Policy and evidence effects are durable; verification and assertion effects are non-durable gates. The [PlatformReleaseApplicationAuthority](../../app/Runtime/Configuration/PlatformReleaseApplicationAuthority.php) is temporary, release-bound, non-human and non-durable. It exists only in the controlled CLI provisioning context, is bound to the exact release/artifact/Genesis/mapping identity, is unavailable through HTTP, is not a Principal, credential or AuthorityGrant, cannot authorize normal runtime mutation or substitute for Principal authorization of `business.create`, and expires with the opening application. Opening evidence is recorded only in `platform_opening_applications`, not in `schema_migrations`, `genesis_runs`, normal Command execution or IDY-008 workflow execution. The ledger binds application identity, release, artifact, Genesis, mapping, approved effect inventory, verification results, conflict/reconciliation information, technical provenance and timestamps, without a Principal dependency. `APPLIED` is the successful state; a repeat of the exact application durably transitions to `ALREADY_CURRENT` after reconciling every approved Operation/Policy effect; a safely established mismatch durably records `CONFLICT`; an incomplete or uncertain existing record durably transitions from the transient `NEW` marker to `RECONCILIATION_REQUIRED`. The applicator never creates `NEW`; it is reserved for an incomplete pre-application record and is not a separate durable opening phase. No conflict or reconciliation state is converted to `APPLIED`, and actual Operation/Policy effects remain atomic. This reconciliation rule closes the previously permitted drift in which an `APPLIED` ledger row could coexist with missing `principal.register` and `principal.confirm` Objects. Focused opening evidence: `PlatformOpeningApplicatorTest` passed 7 tests / 20 assertions, including exact apply, idempotent re-application and recovery of missing approved effects under an existing `APPLIED` ledger row. The full disposable PHPUnit suite passed 353 tests / 1,332 assertions with 0 failures and 0 errors; it reported 5 existing warnings, 2 PHPUnit deprecations and 1 skipped test. The CLI selector gate passed for missing and non-target selectors; foundation and Genesis regressions remain covered by the full suite. These checks used only the disposable local `IDY_TEST_*` database where a database was required. No target provisioning command was run and no production database or deployment configuration was touched. #### Fresh disposable provisioning validation The test-only [fresh disposable provisioning harness](../../bin/run-disposable-provisioning-e2e.ps1) creates a unique `IDY_TEST_E2E_<32 uppercase hex characters>` database for each run using the protected local MariaDB operator configuration, grants only the configured test application user access, exports `IDY_TEST_DB_*`, and invokes [disposable-provisioning-e2e.php](../../bin/disposable-provisioning-e2e.php). The PHP harness requires the exact generated identity, verifies `SELECT DATABASE()`, rejects the production identity and non-test names, refuses any pre-existing table, and uses no credentials in arguments or output. Cleanup drops only the exact generated identity after revalidation; `-KeepDatabase` is an explicit diagnostic retention option. The validated command is: `powershell.exe -NoProfile -ExecutionPolicy Bypass -File bin/run-disposable-provisioning-e2e.ps1` It exercises the same reusable components as the controlled target path in this order: `EMPTY` -> `MIGRATED` (all 15 checked-in migrations through `0014_retryable_confirmation_challenges`, ledger and checksums) -> `GENESIS_COMPLETE` (IDY-003 foundation-only state and no human state) -> `PLATFORM_OPENING_READY` -> `PLATFORM_OPENED APPLIED` (approved artifact, mapping digest, three Operations, Policy, trusted handlers, and eleven-effect evidence) -> `VOCABULARY_READY` (Platform, Evidence and Governance descriptors required by the current target composition) -> `RUNTIME_READY`. Runtime composition is then checked through `/health`; it does not run migrations, Genesis or platform opening. After provisioning, the harness uses the real `TargetRuntimeCompositionRoot` and boundary for Principal registration, confirmation, authentication and governed `business.create`. It verifies the three Operations and trusted handler paths before exercising the genuinely fresh registration lifecycle, then verifies Business/Membership/Business AuthorityGrant/Policy effects and Command/action/attempt/outcome/provenance/event evidence. It does not seed or create Principal, credential, Business, Membership, AuthorityGrant, Policy or continuing human authority during provisioning. The current disposable run reached the canonical 15-migration ledger and runtime provisioning checks, then stopped at the existing `Principal confirmation or bounded onboarding authority failed` assertion before IDY-008 and demonstrator initialization; the disposable database was cleaned. This is not initializer evidence and does not alter the separate production command `bin/provision-target.php --database=target`, its fixed `idio2plat` identity, or production environment/configuration. **Status:** MIGRATION COMPATIBILITY VERIFIED LOCALLY; FULL DISPOSABLE PROVISIONING BLOCKED AFTER MIGRATION. The legacy `0013_retryable_confirmation_challenges` compatibility path passed the focused database-backed test with 1 test and 6 assertions, covering unchanged legacy evidence, no re-execution and second-run emptiness. Invalid-checksum and both-ID compatibility cases require a separate isolated database fixture because MariaDB DDL in the runner commits the surrounding transaction; they are not claimed here. The later onboarding blocker prevents claiming platform-opening or initializer verification from the current disposable run. Production remains blocked pending separate target deployment, operator authorization, live backup/restore and hosting verification. ### IDY-001 to IDY-009 Contract-Freeze Disposition | Stage | Current disposition | Boundary | | --- | --- | --- | | IDY-001 | CLOSED / FROZEN | Repository isolation and target-boundary evidence remains valid. | | IDY-002 | DOCUMENTATION AMENDMENT | Foundation/runtime prerequisite wording is clarified; no application behavior is claimed. | | IDY-003 | FOUNDATION CONFORMANCE SLICE VERIFIED | Foundation-only Genesis artifact integrity, foundation-only seed checks, fresh-store refusal and existing idempotence/integrity evidence are implemented; the prior human-bootstrap path remains superseded. | | IDY-004 | CLOSED / CURRENT LIFECYCLE VERIFIED | The focused result is **14 tests / 87 assertions: 13 passed, 1 intentional skip and 0 failures**. Current registration, confirmation, authentication, governed Business creation, Business inspection authorization, governed history/revision, bounded object listing, freshness invalidation and cross-Business context isolation are covered by the modernized focused fixture. The malformed-principal source-accounting contract is resolved and verified. The inactive Policy activation/deactivation lifecycle remains intentionally deferred. | | IDY-005 | CLOSED / FROZEN BOUNDARY | Governed mutation, Command, evidence and commit semantics remain the shared mutation boundary; admission operations do not weaken it. | | IDY-006 | CLOSED / FROZEN | The bounded Graph + generic UI contract is complete. 006A graph evidence passed **13 tests / 108 assertions**; 006B presentation evidence passed **12 tests / 68 assertions**; and the authenticated 006B HTTP acceptance passed **139/139 checks**, with 0 failures, 0 skips, 0 runtime diagnostics and clean server shutdown. The human-without-SQL exit criterion is satisfied: the journey authenticates, selects Business context, inspects authorized objects and relationships, uses a declared transition form, submits a governed Command and inspects resulting Command/evidence output. Presentation tests confirm delegation through the existing `CommandHandler`; authorization, cross-Business isolation and denied-field non-disclosure remain enforced. | | IDY-006A | CLOSED / FROZEN | Relationship creation, indexing, integrity, cardinality and authorized traversal are implemented and verified. Focused graph evidence: **13 tests / 108 assertions**, 0 failures, 0 errors, 0 risky and 0 skipped. Universal relationship retirement/end/update/supersession/deletion remains deferred and is not an IDY-006 closure requirement. | | IDY-006B | CLOSED / FROZEN | Generic View/Form definitions and server-rendered projection are implemented and verified. Focused presentation evidence: **12 tests / 68 assertions**. The independent HTTP acceptance passed **139/139 checks**, with 0 failures, 0 skips, 0 runtime diagnostics and clean server shutdown. The former `07c` relationship-ID assertion was a test-contract mismatch: HTML exposes the authorized endpoint label, endpoint ID and direction, while the machine-readable projection retains the addressable relationship ID. Authorized relationship endpoint labels now link to the canonical `/objects/{objectId}` route; object identity remains `objects.id`, and resolution continues through the existing authorized object reader and Business context. | | IDY-007A | CLOSED / FROZEN | Workflow vocabulary and Node binding remain unchanged. | | IDY-007B | STATUS RECONCILIATION ONLY | Existing admission evidence remains Business/workflow-scoped; registration and confirmation are not workflow expansion. | | IDY-007C | PARTIAL / VERIFIED | The bounded governed dispatch lease and five-target finalization path is implemented through the Business-owned `workflow_dispatch` Operation, exact Operation resolution, `OperationInvocationService`, `CommandHandler`, Authority/Policy checks, expected-version and conditional resource-claim fencing, fixed dispatch participation and generic Command/Attempt/Outcome evidence. IDY-007 verification passed **58 tests / 231 assertions**, including **19 finalization tests / 98 assertions**; stale/expired/wrong-worker/wrong-token rejection, rollback, idempotency and one-winner concurrency are covered. A post-commit Event hook now invokes the bounded runner, which admits matching Workflows, claims leases, steps the interpreter and reloads persisted status. Waiting wake, expired-lease reclamation, richer reconciliation/recovery and database-backed end-to-end verification remain deferred/unverified. | | IDY-008 | PARTIAL / FOCUSED GENERIC INSTALLER VERIFIED | Reusable Business-scoped configuration requires an existing governed Business; it does not install platform opening, identity lifecycle, Business identity or authority prerequisites. Release identity/digest is Business-independent while runtime declarations, Commands and provenance bind to the authenticated Business. | | IDY-009 | COMPLETE / BOUNDED HTTP DEMONSTRATOR VERIFIED | The generic Business-scoped Enquiry -> Qualification -> Decision -> Project demonstrator passes the retained dedicated HTTP artifact at `var/http-acceptance/idy009-result.json`: 53 checks passed, 0 failed, with no runtime diagnostics and clean server shutdown. Focused installer, Enquiry, Qualification/Decision/Project integration and IDY-006B HTTP regression checks also pass. No Spearmint Business, Principal, Membership or Authority identity is created or seeded; the demonstrator artifact remains test-trusted only and no production trusted release exists. | | IDY-010 | CLOSED / BOUNDED SURFACE UI VERIFIED | IDY-010 implementation is closed at its bounded authoritative scope. The existing generic server-rendered Business surface provides a readable authenticated shell, server-resolved Business context, generic Enquiry and Qualification View Definitions, authorized object reads through `AuthorizedObjectReader`, and declared Operation forms. Enquiry list/detail and Qualification list use `PresentationCatalog`/`PresentationProjector`; Operations remain resolved through `OperationInvocationService` and mutations through `CommandHandler`, with AuthorityGrant/Policy checks, expected-version protection and governed Command/evidence preserved. The Enquiry -> Qualification read/result loop is implemented. The canonical `idy010` HTTP acceptance artifact records **69/69 HTTP acceptance ÔÇö PASS**, with zero failures, zero runtime diagnostics and clean shutdown. The earlier **51/51** result is historical/intermediate evidence. This verifies the bounded Surface UI increment only; the Surface is intentionally not a finished/full product UI, and broader capabilities remain future/refinement work rather than unresolved IDY-010 defects. | IDY-001 -> IDY-009 remain frozen/current contractual territory. IDY-010 is established as the next major stage, but no UI functionality is claimed merely because underlying runtime or legacy UI capability exists. IDY-011+ are provisional future stages only; no future stage is implemented, verified or frozen here. The provisional Business Configuration Domains are open-ended capability areas, not mandatory independent modules or a fixed catalogue. | Requirement and owner | Current evidence boundary | Required discriminating evidence | | --- | --- | --- | | Identity/Permission: [identity and governance](../architecture/identity-and-governance.md) | Focused Principal admission, authentication, platform onboarding authority and initial Business governance are verified; broader permissions remain unverified | Cross-Business isolation, object/type/relationship permissions and governed action checks | | Object/Data: [objects and types](../architecture/objects-and-types.md) | Old domain persistence is not universal type/address implementation | Valid/invalid typed values across every persistent/addressable category, addressable type definitions and permitted nested scalars | | Relationship: [business model](../architecture/business-model.md) | Foreign keys in old tables do not establish the shared relationship contract | Addressable relationships, endpoint integrity and cross-capability reuse | | Business DNA and semantics: [business model](../architecture/business-model.md), [semantics](../architecture/semantics.md) | Brand fields and campaign settings are not a business-model runtime | Inspectable/configurable business representation in the same model, with approved rule/policy/constraint/goal/decision meanings | | Event: [time and events](../architecture/time-and-events.md) | Old activity feed is not a general Event Engine | Recorded/effective-time and causal/provenance behavior; explain why an action occurred | | Workflow: [workflows and automation](../architecture/workflows-and-automation.md) | Saved editor actions and workflow badges are not executable workflow definitions | Deterministic definition/node execution, version binding, approval, transitions and outcomes | | Knowledge: [knowledge](../architecture/knowledge.md) | Visible textareas/files do not establish knowledge authority or retrieval | Knowledge outside ordinary properties, related objects, source/provenance and historically identifiable changes | | Retrieval: [retrieval](../architecture/retrieval.md) | Old scoped SQL queries are not the platform retrieval contract | Structural narrowing by type/relationships/state/time/permissions; optional constrained semantic retrieval | | Content: [views and content](../architecture/views-and-content.md) | WordPress markup and logo uploads are limited adapter/UI assets | Shared content/media references, authorized edits and lifecycle/history behavior | | View/UI: [views and content](../architecture/views-and-content.md) | Hard-coded templates, not model-generated applications | Editable view/form/navigation definitions rendered against the same authorized model | | Communication: [communication and integrations](../architecture/communication-and-integrations.md) | Activity previews do not establish messaging or notification delivery | Distinct messages/delivery state, authorization, failures and traceable outcomes | | Integration: [communication and integrations](../architecture/communication-and-integrations.md) | Concrete WordPress calls only, not a provider-neutral core contract | Per-connection supported operations, normalized tools, safe failures and secret boundaries | | Analytics: [analytics and evolution](../architecture/analytics-and-evolution.md) | Analytics page is a placeholder | Reproducible historical measures, scoped retrieval and explained results | | Automation/Scheduling: [workflows and automation](../architecture/workflows-and-automation.md) | No general scheduler/worker; active flags do not execute work | Approved trigger/schedule/job distinction, retries, concurrency, cancellation, timezones and missed-run behavior | | AI/Intelligence: [AI](../architecture/ai.md) | Optional Groq generation is an adapter-specific example only | Controlled retrieval, validated proposals and authorized execution; core works with AI absent or unavailable | | Evolution/Optimisation: [analytics and evolution](../architecture/analytics-and-evolution.md) | No observation-to-improvement loop evidenced | Observation, suggestion, review, approved change and measurement with provenance | | Cross-capability demonstrator: [composition and extensibility](../product/definition.md#composition-and-extensibility) | Disconnected old screens do not prove model reuse | A new useful capability assembled from shared types/relationships/workflows/views without bespoke foundations | The fourteen engine responsibilities need not map to fourteen services; retrieval and shared-model acceptance cut across them. Required checks and no-AI/security negatives are detailed in [development](development.md#architecture-conformance-gates). The first demonstrator is the generic Business-scoped Enquiry -> Qualification -> Decision -> Project sequence. Historical Spearmint Design references are product provenance only and are not an IDY-009 platform, Business or runtime dependency. Broader product scenarios do not expand that milestone into a generic CRM. ## First Milestone Evidence | Area | Chosen mechanism | Current implementation status | |---|---|---| | Runtime/store | PHP 8.3.33 modular monolith; shared typed objects and retained revisions in MariaDB 10.5.26/InnoDB | Historical IDY-003 generic-store evidence is retained, but the human-bootstrap Genesis path is superseded; foundation-only Genesis and platform opening are NOT BUILT. IDY-005 governed mutation/history slice implemented and validated; IDY-006A/006B and IDY-007A/007B/007C bounded slices validated by the recorded canonical evidence | | Identity/Business/authority | Server sessions, explicit membership/grants and governed Policy evaluator | Bounded registration, confirmation, authentication, membership, Business context and `business.create` are implemented and focused-verified; broader policy/delegation/security coverage remains incomplete | | Commands and commit | Stable unique Command identity; explicit Action Execution/Attempts; expected-version writes; coherent state/history transaction | IDY-005 bounded mutation/history slice validated; generic participating transaction/evidence correction is verified separately below | | Recovery/distribution | Durable claims and execution state; reconciliation for unknown effects; shared process-independent mutation contract | SOURCE IMPLEMENTED; database-backed and authenticated-STAGING verification pending | | UI/login | Model-driven authorised object list/detail/forms and Command/result inspection | IDY-010 bounded foundation implemented and HTTP-verified; generic object list/detail provides readable declared fields, Type/state context and authorized relationship endpoint labels, and configured Operations provide declared-input and existing-target projections. Full Surface UI remains unbuilt | | Genesis | Foundation-only versioned CLI manifest with technical installation provenance; no human/customer runtime state | Foundation-only Genesis conformance hardening is implemented; the deterministic platform-opening release artifact is verified (2 focused tests / 4 assertions). Principal admission, authentication and ordinary `business.create` are implemented and verified only in the bounded lifecycle evidence above; broader runtime coverage remains open. Previous human Principal/credential/Idiosyncrasy Business Genesis evidence is superseded historical implementation evidence and is non-conforming to the frozen contract. | | Generic demonstrator process | Enquiry -> Qualification -> Project/Scoping first, preserving the full intended delivery lifecycle | Bounded Operation handlers, Business-scoped configuration fixture, governed effects and target affordances are implemented; the bounded four-stage HTTP acceptance is verified; production release artifact and deployment remain outstanding | | Runtime invariant suite | PHPUnit plus isolated InnoDB race/failure fixtures and fake external adapter | Canonical baseline: PHP 8.3.33, PHPUnit 11.5.56, 187 tests / 895 assertions, 0 failures, 0 errors, 0 risky, 0 skipped; broader workflow recovery remains NOT BUILT | ## Bounded Implementation Closure Evidence Evidence recorded 2026-09-16 against the canonical isolated runtime and `.\bin\run-tests.ps1`: | Slice | Status and evidence | | --- | --- | | IDY-005 governed mutation/history | PARTIAL / VERIFIED for the implemented bounded mutation, authorization, expected-version, rollback, relationship-effect, Event/evidence settlement and reconciliation slice: 48 tests / 191 assertions PASS. This does not claim the wider platform mutation or first-milestone acceptance is complete. | | IDY-006A relationship graph | CLOSED / VERIFIED for the bounded Relationship Type, relationship object/index/slot, endpoint integrity, cardinality and authorized traversal slice: **13 tests / 108 assertions, 0 failures, 0 errors, 0 risky and 0 skipped**. Universal relationship retirement/end/update/supersession/deletion remains deferred outside this frozen slice. | | IDY-006B generic presentation | CLOSED / VERIFIED for the bounded presentation vocabulary, authorized generic projection and governed human journey: **12 tests / 68 assertions**, plus **139/139 HTTP acceptance checks**, 0 failures, 0 skips, 0 runtime diagnostics and clean server shutdown. The IDY-010 presentation increments add readable declared values, object detail state context, authorized relationship endpoint labels and a generic Operation input descriptor; they remain separate from the IDY-006 contract and do not make the richer Surface UI part of IDY-006. | | IDY-006 combined Graph + generic UI | CLOSED / FROZEN | The authenticated HTTP journey demonstrates authentication, Business selection, authorized inspection, declared transition form, governed Command submission and resulting Command/evidence inspection without direct SQL. Presentation tests establish delegation through the existing `CommandHandler`; no production PHP change was required for closure. IDY-010 remains the later richer Surface UI/product-learning loop. | | IDY-007A workflow vocabulary | PARTIAL / VERIFIED for the implemented manifest-bound workflow vocabulary installation and validation slice through recorded focused evidence; the current full configured PHPUnit result remains UNKNOWN. | | IDY-007B workflow admission | PARTIAL / VERIFIED for the implemented workflow admission, execution identity, dispatch admission and authority-binding prerequisite slice through recorded focused evidence; the current full configured PHPUnit result remains UNKNOWN. | | IDY-007C bounded lease/finalization | PARTIAL / VERIFIED for the implemented governed dispatch lease, five-target finalization, fencing, authorization, current composition and generic evidence boundary: IDY-007 focused regression evidence passed with 58 tests / 231 assertions, including 19 finalization tests / 98 assertions. Claim, release, all five targets, stale/expired/wrong-worker/wrong-token rejection, rollback, idempotency and one-winner concurrency are covered. Waiting wake, expired-lease reclamation and richer reconciliation remain deferred. | | Generic conditional commit prerequisite | VERIFIED as a platform extension: an optional typed, allowlisted resource-claim predicate flows through Operation plans and Commands into the generic repository's atomic expected-version update condition; satisfied, stale, mismatched, expired and missing claims reject durably, while unguarded updates remain unchanged. Focused evidence: 48 tests / 191 assertions PASS in the IDY-005 mutation suite. IDY-007 dispatch now consumes this predicate through the governed Operation and CommandHandler path. | | Generic transaction/evidence participation | VERIFIED for the generic `CommandHandler` and `SecurityAuditWriter` contract: participating success, outer rollback/retry, authority and Policy rejection, conditional-claim rejection, unknown/reconciliation settlement and audit rollback preserve outer transaction ownership. Focused evidence: 9 tests / 43 assertions PASS; adjacent `OperationInvocation`/`ConditionalCommit`/`Idy005` filter: 60 tests / 267 assertions PASS. | | IDY-007 Slice 1 sequential execution | PARTIAL / IMPLEMENTED, focused verification pending for the newly assembly-wired condition/end interpreter and exact Logic Definition reference path. The implementation supports the approved five finalization targets through Business-owned Operations installed by the configuration boundary. General workflow recovery, wake processing, retry/replay, scheduling and external-effect execution remain outside this slice. | Historical full-suite evidence recorded before the current IDY-010 increment used PHP 8.3.33 and PHPUnit 11.5.56: 349 tests, 1,324 assertions, 0 failures, 0 errors, 5 warnings, 2 PHPUnit deprecations and 1 skipped test. It is not the current full-suite result. Focused evidence also passed for IDY-007 (58 tests / 231 assertions), IDY-005 (48 tests / 191 assertions), Operation invocation (12 tests / 76 assertions) and IDY-008 (25 tests / 121 assertions). The five-target finalization implementation uses the trusted workflow Operation composition, generic CommandHandler conditional commit and fixed dispatch participant; no direct semantic repository writer was added. These results do not establish implementation of a general workflow interpreter, broader workflow recovery/retry/replay, scheduler or queue, external integrations, AI execution, public intake, workflow editor or completed UI. The IDY-007 Slice 1 interpreter intentionally executes only literal/equals condition nodes and end nodes through the existing governed lease/finalization boundaries. IDY-008 remains a focused implementation slice pending its approved release artifact and production trusted-release registration. ## IDY-008 Task 3 Closure Evidence ### Lifecycle and release boundary reconciliation The authoritative lifecycle is: ```text Genesis -> platform opening -> Principal registration -> confirmation -> authentication -> governed business.create -> existing Business -> IDY-008 Business configuration -> normal governed operational activity ``` Genesis and platform opening create only generic platform foundations and capabilities. Principal admission is a runtime operation. `business.create` is a separate governed runtime operation that creates a Business and its initial governance. The demonstrator runs against an existing Business; no Spearmint Design Business exists and it is not a Genesis seed, platform-opening entity, IDY-008 bootstrap object or production special case. IDY-008 is a governed installer for trusted, versioned, reusable Business-scoped configuration. It may create or update Business-owned Types, States, Transitions, Relationship Types, classifications, terminology, domain Policies, Workflow Definitions/Nodes, View/Form Definitions and approved configuration relationships through the existing Command boundary. It must not create a Principal, credential, confirmation/authentication state, Business, Membership, AuthorityGrant, platform authority or operational records such as People, Organisations, Enquiries, Qualifications or Projects. The separate generic Business initialization phase may subsequently create the approved initial operational objects through the installed governed Operations. The `database/configuration/idy-008/demonstrator.json` file is the reusable demonstrator configuration release. Its canonical digest is registered by [Idy008CliCompositionRoot](../../app/Runtime/Bootstrap/Idy008CliCompositionRoot.php) for the normal authenticated CLI installer. It remains configuration-only: it does not contain operational Enquiry, Qualification, Decision or Project instances, and no operational data is created by configuration installation. ### Deliberately unchanged release and deployment boundaries The following boundaries remain explicit after the generic installer implementation: - `ConfigurationReleaseVerifier` requires only reusable release identity, version, release ID and declarations; it rejects tenant-bound root identity fields. - `ConfigurationManifestValidator` binds the server-resolved Business to validated declaration copies; the trusted canonical release and digest remain unbound. - `ConfigurationCommandCompiler` includes the target Business in derived Command identity and compilation. - Configuration declarations are restricted to Business-scoped configuration kinds; Principal, Membership, AuthorityGrant, Business and operational identity declarations are rejected. - `bin/install-idy008.php` uses the demonstrator release path, requires an authenticated Principal and existing Business argument, and submits installation through the governed Command path. - `Idy008CliCompositionRoot::fromExisting()` registers the checked-in release identity/version/digest; `forTesting()` remains available for isolated alternate-release tests. These are later implementation and, where necessary, contract-enforcement tasks. They are not evidence that Spearmint has been provisioned and are not changed by this reconciliation. **Implementation status:** **IMPLEMENTED / CONFIGURATION INSTALLER ENABLED; OPERATIONAL PROVISIONING NOT CLAIMED** The generic IDY-008 path and focused governed installer are implemented, including the checked-in demonstrator release registration. The active contract keeps operational records outside the configuration manifest. The generic initializer supplies bounded runtime inputs and invokes the installed Operations; it does not introduce a manifest seed format or arbitrary production data artifact. The following bounded requirements are implemented and focused-tested: - release integrity, canonical SHA-256 verification and fail-closed trust for explicitly injected test release definitions; - strict manifest validation, Business identity/isolation, exact Type identity/revision handling, typed values, classifications, dependencies, workflow declarations and bindings, relationship declarations, and presentation declarations; - shared presentation Type/reference semantics between [PresentationTypeResolver](../../app/Runtime/Presentation/PresentationTypeResolver.php), [PresentationCatalog](../../app/Runtime/Presentation/PresentationCatalog.php) and installer validation; - deterministic dependency-ordered generic create/update/relationship Command compilation, IDs and fingerprints, including same-release relationship endpoint resolution; - installation through the existing governed `ConfigurationInstaller` -> `ConfigurationCommandCompiler` -> `CommandHandler` path, with server-resolved authorization; - durable Command, Action Execution, Attempt, Outcome and Provenance evidence; - deterministic installation-state classification, including safe unresolved-work classification and prohibition of blind replay. Focused evidence on 2026-09-18 used PHP 8.3.33, PHPUnit 11.5.56 and the isolated MariaDB test environment. `Idy008InstallerTest.php` passed **12 tests / 68 assertions**. The adjacent `ConfigurationReleaseVerifierTest.php` and `Idy008AAccessTest.php` run passed **16 tests / 45 assertions**. Combined focused evidence is **28 tests / 113 assertions**, with zero failures and zero errors. It covers canonical digest verification, reusable release installation into two Businesses with the same digest and distinct Business-scoped runtime object/Command identities, same-release endpoint scoping, idempotency, drift/conflict, durable unknown/rejected evidence, pre-mutation rejection, forged target fields, identity/authority/operational declaration rejection, server-resolved authorization and cross-Business isolation. Production files reported no editor diagnostics. The production artifact and CLI smoke path remain unverified because the approved artifact and trusted registry entry do not exist. The implementation introduced no installer-specific reconciliation engine, recovery/retry/replay engine, new mutation boundary, authorization architecture or installer persistence aggregate. Model C remains the governing reconciliation determination: existing durable evidence is inspected and classified, unsafe continuation is refused, and no new installer recovery engine is required. ## IDY-009 Create Enquiry Boundary **Implementation status:** **COMPLETE / BOUNDED DEMONSTRATOR VERIFIED** The first IDY-009 slice adds the fixed `create_enquiry` handler and Enquiry Type descriptor vocabulary. It accepts source, summary, received time and an explicit `unmatched: true` input, then creates an Enquiry in `received` with `contact_status: unmatched` and server-owned `created_by` identity. The handler is registered through the existing trusted Operation registry. The operation uses the Business-scoped `OperationInvocationService`: exact active Operation revision, declaration-driven input validation, server-resolved Business membership, Operation ownership, trusted-handler allowlisting and Operation-level AuthorityGrant/Policy checks remain in force. The service constructs the Command envelope and delegates the Enquiry effect to the existing `CommandHandler`, which remains responsible for mutation authority, idempotency, atomic mutation and durable evidence settlement. Focused handler coverage was added for the unmatched plan and rejection of contact-bearing input. The canonical focused run on 2026-09-18 used PHP 8.3.33, PHPUnit 11.5.56 and `bin/run-tests.ps1 tests/Unit/CreateEnquiryOperationHandlerTest.php`: **2 tests, 8 assertions, 0 failures, 0 errors**, no warnings/risky/skipped tests reported, exit code 0. The unit surface directly exercises the actual trusted `CreateEnquiryOperationHandler` and proves explicit `unmatched: true`, `received` state, `unmatched` contact status, Enquiry Type selection, server-provided `created_by`, and rejection of contact-bearing input. This unit result is intentionally not broader evidence: it does not create a Business, resolve Membership, evaluate AuthorityGrant/Policy, invoke the trusted registry, persist a Command or Enquiry, or prove Command/evidence settlement. Those prerequisites belong to the surrounding Business-scoped `OperationInvocationService` and `CommandHandler` path. The unit passes context values directly because the handler contract receives server-resolved context; it does not bypass or replace the surrounding authorization boundary. The test has no database lookup, so it cannot accidentally match Genesis data. Contact-bearing input remains rejected by the handler itself; removing that guard would fail the second test. Invocation-level integration evidence was then added with the legitimate `Idy006BFixture` Principal/Business/Membership path, an exact active Business-scoped Operation revision, the trusted handler registry, and explicit operation/mutation AuthorityGrant and Policy entries. The focused canonical run on 2026-09-18 used `bin/run-tests.ps1 tests/Integration/CreateEnquiryOperationInvocationTest.php`: **3 tests, 34 assertions, 0 failures, 0 errors**, no warnings/risky/skipped tests reported, exit code 0. The successful invocation asserts settled Command and Outcome records, exact Command-effect-to-Enquiry identity linkage, Enquiry Type and revision, Business ownership, source/summary/received time, unmatched received state, and persisted Enquiry `created_by` equal to the server-resolved fixture Principal. The test also checks Command-linked Enquiry revision provenance, but does not independently assert the durable Provenance object's own `principal_id` or `business_id`. Guard sensitivity is covered by denial without Command creation when Operation authority is absent, and settled rejected Command evidence with no Enquiry when final mutation authority is absent. This proves the bounded explicit-unmatched invocation/persistence slice only; contact resolution, the remaining Spearmint operations and broader workflow behavior remain unverified. The remaining three approved operations are now implemented through the same Business-scoped `OperationInvocationService` and trusted handler registry. The bounded integration fixture declares the Enquiry, Qualification, Decision and Project Types, required States, Transition Definitions, Relationships, active Operation Contracts and explicit AuthorityGrant/Policy objects through the existing generic object/configuration mechanisms; it is test configuration only and is not a production release artifact. Focused IDY-009 evidence on 2026-09-18 used PHP 8.3.33, PHPUnit 11.5.56 and the isolated MariaDB test environment: `DemonstratorQualificationOperationInvocationTest.php` passed **9 tests / 42 assertions / 0 failures / 0 errors**. It covers successful Qualification submission with create + relationship + transition effects, durable Command/Outcome/Provenance/Event evidence, invalid input and state, stale expected versions, reviewer/submitter separation, positive-decision Project gating, duplicate prevention, cross-Business denial, replay/conflict behavior, rollback and standalone transition declaration availability. The target surface now exposes authenticated Business context, authorized object lists/details, history, relationships, graph and Command evidence, plus a generic Business Operation form and JSON/HTML invocation routes. Operation mutations pass through `OperationInvocationService` and then the governed Command/effect path; CSRF, membership, exact Operation revision, authorization and durable evidence remain server-owned. The dedicated IDY-009 HTTP acceptance proves the complete bounded Enquiry -> Qualification -> Decision -> Project sequence through that surface, including the distinct reviewer and final Project effects. The surface is intentionally bounded and does not provide public intake, AI execution or later lifecycle stages. The established HTTP acceptance command `bin/run-http-acceptance.ps1 -Suite idy006b` was rerun on 2026-09-18 after correcting the stale `07c` expectation. The suite passed **139/139 checks**, with **0 failures, 0 skips, 0 runtime diagnostics**, clean server shutdown and exit code 0. `07c` now verifies the established authorized HTML projection by asserting the endpoint label; the adjacent checks retain endpoint identity, outgoing direction, cross-Business non-disclosure and secret-field exclusion. The relationship ID remains covered through the machine-readable relationship projection and focused graph evidence; no production relationship-ID rendering was introduced. Together with the focused 006A and 006B presentation results and the authenticated human-without-SQL journey, this is the final bounded IDY-006 acceptance evidence. The dedicated command `bin/run-http-acceptance.ps1 -Suite idy009` produced the independently retained `var/http-acceptance/idy009-result.json`: **53 checks passed, 0 failed, 0 runtime diagnostics, clean server shutdown, exit code 0**. It proves the complete bounded Enquiry -> Qualification -> Decision -> Project sequence through normal authenticated HTML operations, including distinct reviewer execution and settled Command evidence for each operation. The acceptance is limited to the disposable test-trusted demonstrator artifact; it does not establish a production trusted release or deployment. ## IDY-008 Focused Verification Evidence **Executable verification status:** **VERIFIED for the focused repair; broader evidence remains limited** The focused PHPUnit command was executed with the pinned PHP 8.3.33 runtime and PHPUnit 11.5.56 through the direct invocation path. The Type-of-Type validator now uses descriptor validation, installer command/evidence classification accepts the canonical persisted `JsonObject` representation, and Presentation Type resolution normalizes nested stored objects without weakening fail-closed handling. Focused results on 2026-09-17 were: TypeDescriptorValidatorTest 15 tests/21 assertions, Idy008InstallerTest 9/36, Idy006BPresentationTest 10/65, GenericStoreAndGenesisTest 19/44, BusinessCreationOperationHandlerTest 2/13 and Idy008AAccessTest 11/40; all passed with zero failures and zero errors. The canonical PowerShell runner remains unavailable because its `Start-Process` argument list contains a null element: - Tests executed: 66 focused tests - Assertions executed: 219 - Exit status: 0 for every listed group - Failure point: none in the listed focused groups; Graph remains outside this build This is not a test pass and is not described as a test failure. The full configured PHPUnit result is **UNKNOWN ÔÇö the full configured PHPUnit run was previously stopped before producing a final summary.** The `mbstring` limitation is an independent environment verification task and does not reopen IDY-008 implementation. Approved production Spearmint manifest content, trusted production release ID/digest configuration, the production trust registry, the target Business, required Membership/AuthorityGrant/Policy and required platform prerequisites remain deployment/release prerequisites, not IDY-008 Task 3 implementation defects. No production release artifact is invented by this status entry. **IDY-003 evidence recorded 2026-09-13 (superseded):** the frozen `database/genesis/idy-003.json` manifest was verified at 6217 canonical UTF-8 bytes with SHA-256 `7edab9d7dad935ae9ea0ba81d78968ea6b6f75b5f87e99ea89f9f48e792c6908`. Two historical evidence records report 26 tests/63 assertions and 30 tests/73 assertions; the later record includes Genesis Occurrence revision/timestamp integrity. Both describe the previous human-bootstrap implementation and therefore do not establish conformance to the now-frozen Foundation-only Genesis contract. The underlying generic-store and idempotency evidence remains historical. Its older conclusion that foundation-only Genesis, platform opening, registration, confirmation/onboarding and ordinary `business.create` remain NOT BUILT is superseded by the current evidence matrix above; foundation-only Genesis and platform-opening status remain separately bounded by their named evidence. The milestone is authenticated entry into an authorised Business, addressable object inspection and a governed state change through Command -> Validation -> Authority/Policy -> Commit, with addressable state transition and provenance/history. Runtime conformance is not established until the [specified tests](development.md#invariant-test-specification) pass. ## Test Execution Infrastructure Evidence **Status:** **FOCUSED OPERATION INVOCATION VERIFIED; BROADER PLATFORM UNVERIFIED** **Superseded historical analysis:** The full-suite reset remediation on 2026-09-18 centralized `WorkflowDefinitionValidatorTest`, `Idy004AccessTest`, `Idy007CFinalizationTest`, principal-admission hardening setup and the HTTP `FixtureInstaller` on `TestDatabaseContext::resetFoundation()`. That helper deletes current FK children, including `principal_confirmation_challenges` before `principal_identities` and both before `objects`, while retaining FK enforcement. The embedded IDY-007C worker callers were also updated to pass the existing PDO to the current two-argument `PrincipalRepository` constructor; production composition roots were not changed. An earlier focused IDY-004 checkpoint reached six historical authentication/business-context fixture failures plus the separate malformed-input rate-limit contract boundary; its missing IDY-005 vocabulary prerequisite was corrected by installing the authoritative platform vocabulary. The complete PHPUnit suite was then recorded as non-green for those seven historical IDY-004 failures, with no FK-reset or stale-constructor errors returning. Subsequent work resolved the malformed-input boundary; the final IDY-004 evidence and current disposition are recorded above. The pinned PHP 8.3.33 executable was confirmed to launch through the existing VS Code task. Captured probes showed that `bin/run-tests.ps1` passed the space-containing PHPUnit PHAR path through `Start-Process -ArgumentList`, which split the path at `F:\-` and prevented PHPUnit from opening. The runner also passed a duplicate `-dextension=mbstring`; the pinned runtime already loads `mbstring`, and PowerShell treated the resulting native warning as a terminating error under its strict error policy. The smallest infrastructure correction replaced that process launch with the PowerShell call operator while retaining separate temporary stdout/stderr capture and PHPUnit exit-code propagation, and removed the redundant extension flag. The disposable diagnostic wrapper and temporary tasks were removed after verification. The first genuine focused result was **69 tests, 1 failure, 9 errors**, exit code 1. Investigation confirmed the fixture gap and command-ID collision were test defects. Installing the established `Idy006BFixture::installIdentity()` Principal/Business/Membership fixture left operation-specific grants and policies explicit, and replacing the rejected-command ID with reserved UUID `75000000-0000-4000-8000-000000000016` preserved the ÔÇ£no Command was createdÔÇØ assertion without colliding with Genesis or other fixture addresses. The corrected focused result, obtained through `bin/run-tests.ps1 tests/Integration/OperationFoundationTest.php` on 2026-09-18 with PHP 8.3.33, PHPUnit 11.5.56 and isolated MariaDB 10.5.26/InnoDB, is **69 tests, 126 assertions, 0 failures, 0 errors**, with no warnings, risky tests or skipped tests reported, exit code 0. The run exposed and corrected two genuine production defects at the Operation Invocation boundary: nested persisted `JsonObject` operation declarations were not recursively normalized before typed validation, and Business-context/operation-authority denials were not mapped to the invocation contract's `CommandException`/`command_denied` result. No authorization rule was weakened and no alternate mutation path was introduced. A test-only visibility correction allowed the anonymous trusted-handler fixture to reference its declared type constant. The repaired tests remain evidence-bearing rather than setup-only: active Business membership is required by the production resolver; operation-specific AuthorityGrant and Policy remain required by production authorization; the invalid typed-input case must fail before handler/Command creation; the unregistered-handler test exercises the allowlist; the isolation case uses a different Business context; and the successful invocation asserts settled Command state plus Outcome/evidence presence. Removing or bypassing those guards would make the corresponding assertions fail under the current fixture. This is focused evidence for the Business-scoped Operation Invocation Foundation and its Command/evidence delegation only, not broad platform verification. The dedicated Enquiry and downstream IDY-009 integration and HTTP acceptance evidence is recorded above. The current configured full PHPUnit run was stopped before PHPUnit produced a final summary; its result is **UNKNOWN**. The test-only [TestDatabaseContext](../../tests/Support/TestDatabaseContext.php) now validates the bootstrapped MySQL PDO and `IDY_TEST_` scope, and centralizes the repeated foundation reset list for adopted integration fixtures. This improves setup diagnostics and reduces reset-list drift without creating domain fixtures or weakening authorization tests. ## Old Reuse Dispositions These labels apply to candidate material, not completed code changes or certification. | Disposition | Meaning | | --- | --- | | RETAIN | Preserve compatible knowledge or a visual/practice baseline, with explicit scope | | REFACTOR | Reuse may be worthwhile after boundary, security, integration or maintainability work | | REPLACE | New architecture requires a different implementation or binding | | REMOVE | Do not carry the obsolete behavior/assumption into the target; no deletion is performed by this document | | REFERENCE ONLY | Historical context or technical lesson, not a build contract | ## Old Asset Inventory The former marketing application, old controllers, views, services, repositories, assets, schema and setup utilities were retired from the workspace. Their design and implementation observations remain available in [legacy implementation reference](../reference/legacy-implementation.md) as historical, non-authoritative context only. No deleted legacy path is part of the target release or a current implementation contract. Detailed old behavior/gaps live in [legacy implementation reference](../reference/legacy-implementation.md); do not duplicate a full application inventory in each engine document. Reusable tokens/interactions live in [UI system](ui-system.md), mechanisms/configuration in [security and operations](security-and-operations.md), and backend specifics in [WordPress](wordpress.md). ## Foundation View Removal and Initial Business Authority **Implementation status:** PARTIAL / EVIDENCE LIMITED. The runtime no longer uses the legacy `FOUNDATION_VIEW` identity or its `allowed_type_ids`/`fields` allowlist. `AuthorizedObjectReader` now enforces governed inspection, exact Business scope and the canonical machine projection `id`, `type_id`, `type_revision`, `current_version`, `value`. Relationship reading retains separate inspection and traversal authorization and relationship integrity checks. The obsolete `FoundationInspection` helper and hard-coded identity were retired. Genesis was not modified. `BusinessCreationOperationHandler` now emits the Business, creator Membership, an allowing Business-scoped Business-Type inspection grant/policy and an allowing Business-scoped `platform.install_configuration` grant/policy targeting `TYPE_OF_TYPE`. View/Form Definitions remain presentation/configuration and are not authority sources. `TypeDescriptorValidator` now recursively rejects the exact normalized credential-field names defined by the Objects and Types contract before `GenericObjectRepository` create/revise persistence. Ordinary substring fields remain valid. A read-only audit was attempted against the isolated object and revision stores before enabling the validator; the first audit completed without exposing values, but its detailed output exceeded the execution display limit, so complete row-level audit counts remain an evidence limitation. No remediation or data mutation was performed. Focused PHPUnit verification uses the pinned PHP 8.3.33/PHPUnit 11.5.56 direct invocation because the canonical runner exits before PHPUnit when `Start-Process` receives a null argument-list element. Group-level results are the evidence boundary; no full-suite claim is made. The focused repair evidence now includes: `TypeDescriptorValidatorTest` 15 tests / 21 assertions / 0 failures / 0 errors; `GenericStoreAndGenesisTest` 19 / 44 / 0 / 0; `BusinessCreationOperationHandlerTest` 2 / 13 / 0 / 0; `Idy008AAccessTest` 11 / 40 / 0 / 0; `Idy008InstallerTest` 9 / 36 / 0 / 0; and `Idy006BPresentationTest` 10 / 65 / 0 / 0. The remaining four IDY-006 Graph failures were caused by a fixture contradiction: the fixture described a relationship Type as hidden while granting both inspection and traversal for it. The fixture now authorizes only the visible relationship Type; production Graph code was not changed. `Idy006GraphTest` then passed with 13 tests / 108 assertions / 0 failures / 0 errors, including the four hidden-Type pagination, bounds, cursor, and filter cases. These are bounded direct-run results, not a full-suite verification claim. ## Contract and Mechanism Dependencies [D01-D10 are settled](../governance/decisions.md). Canonical owners define semantics, [implementation architecture](architecture.md) chooses mechanisms, and this document records evidence. PHP/MariaDB is the chosen initial mechanism, not the logical definition of Idiosyncrasy or a migration obligation. Broader integrations, advanced scheduling, automated extraction, optional AI and the later Spearmint stages remain unbuilt; they do not block the bounded foundation or reopen architecture. ## Evidence Update and Exit Gate Promote a row to PARTIAL only when a named slice of the new canonical contract exists, not when an old analog is found. Promote a requirement to VERIFIED only with a reproducible check and its scope/limits; failed, unavailable and unrun checks remain visible. Use focused manual verification until a real suite exists, then record its actual command rather than an assumed runner. Recheck links and source coverage before old documentation removal; approval of this inventory does not authorize deletes or runtime changes. This documentation pass validates document structure and references only. It does not run setup, deploy, test live credentials or certify application behavior. ## Presentation vocabulary provisioning correction — 2026-10-14 The deployed generic Business Presentation reconciler correctly reached the governed `object.create` Command, but STAGING settled that Command as `unknown` because the platform-owned Presentation Object Type was absent. The persisted Business, Dashboard, Overview and title state was unchanged. The missing Type is a target vocabulary provisioning gap, not a Business profile or authorization defect. The correction adds `PresentationVocabulary::install()` to the established target provisioning runner and makes the idempotent runtime vocabulary installer available to the target release. The authenticated Business Presentation reconciliation boundary also ensures the same platform vocabulary is current before it submits tenant-scoped Object Commands. The existing staging database identity and one-Genesis preconditions remain enforced for the CLI path. This restores platform vocabulary without direct SQL or Business-data mutation. The generic Business reconciliation continues to create Dashboard and child Presentation Objects only through governed Commands. This correction is implemented and locally package-verified at 214 release files. GitHub Actions run `38412907829` (workflow run 343) deployed commit `e5778e23c019b44855afeb94eeba6c2109fb5049` successfully to STAGING as release `IDY-TARGET-e825312cf382568dfe2a935b832fba2b5ec950204228ea66a8c60b5e5061f494`. The staging health check returned a connected, boundary-ready target runtime. The authenticated browser session retained the existing Principal and Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275` and observed `/` redirect to Dashboard `87c1954c-7810-445c-85dd-1bdc96a6f10f`. The persisted navigation rendered `Dashboard` and `Overview`; the Overview Presentation Object `7302b84a-e3df-485c-8442-c8707334b08d` resolved successfully. Before the correction, the same request returned HTTP 503 with no navigation; after the correction it rendered the Dashboard and Overview surface. The generic profile contains no demonstrator-only operational records. Direct post-repair row-level diagnostic output was not rerun after this browser verification, so the browser-visible projection is the evidence boundary for the final presentation state. ## Functional Business surface increment — 2026-10-13 The next bounded increment is implemented locally but not yet deployed or authenticated-exercised on STAGING. It preserves the generic Presentation architecture and adds: - a revision-2 data-defined Dashboard profile with all eight foundational catalogue entries; - generic persisted internal-route delivery for capability workspace links; - a governed, idempotent Business capability configuration boundary installing Person, Organisation and Project list/detail Presentation Definitions; - a generic Business record service using authorized reads and governed generic Object create/update Commands for People, Organisations and Projects, including expected-version checks; - Business profile editing through a governed Business update Command and the existing initialization workflow for contact email and address; - persisted layout/navigation configuration that keeps unsupported capability record operations explicit rather than presenting decorative controls. The six catalogue entries without record operations remain presented but explicitly deferred; no demonstrator configuration or records are installed by the new generic profile. Local PHP runtime lint and target package verification pass with 223 files. PHPUnit dependencies and the approved database-backed test environment remain unavailable locally. STAGING deployment, capability configuration reconciliation, Business profile input, People/Projects create-edit journeys and post-reload verification remain pending the next release. ### Functional Business surface STAGING verification — 2026-10-13 The capability implementation was deployed by GitHub Actions run 345 from commit `f73650abec9a52b51438636b5fafedd768e09b25`; the persisted record presentation-template correction was deployed by run 346 from commit `10621a42bf080fdbec39689cb03791826c550cf2`, release `IDY-TARGET-890a04b8332e79573505ee73284fb043b633215c95410e9d89a9dd84d46ca4ec`. Both build/artifact verification and STAGING health checks succeeded. Against the existing Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275`, authenticated browser verification observed: - Dashboard navigation contains all eight persisted catalogue entries: People, Products & Services, Sales, Marketing, Projects, Operations, Finance & Accounts and Knowledgebase. - People and Projects open their Business workspaces; unsupported catalogue entries are visibly presented but explicitly report that record operations are not configured in this increment. - The governed capability configuration reconciliation succeeded without creating a replacement Business or demonstrator records. - A staging test Person was created as `STAGING Acceptance Person 2026-10-13`, edited to `STAGING Acceptance Person Edited 2026-10-13`, and the edited value remained visible after reload. Its Object identity is `4f8d66d2-4254-4d8e-ac6c-95e43fa7c962`. - A staging test Project was created as `STAGING Acceptance Project 2026-10-13`, edited to update its objective and status to `active`, and the edited state remained visible after reload. Its Object identity is `68ea1cdd-deaf-4859-8f4f-fa04b09f2a15`. - Business settings remained on the same Business. The user-supplied `stuart@spearmintdesign.co.uk` primary contact email was saved through the initialization workflow; the persisted initialization execution `de65213f-c5d6-42e4-b56a-e4c8d91edbc4` is now `initialized`, while the optional address remains empty. The first post-create Person redirect exposed a missing persisted record template and returned 404; no create was rolled back or duplicated. The record-template correction was then deployed and the same existing Person resolved and edited successfully. The current acceptance evidence is browser and deployed-runtime evidence; row-level post-verification diagnostics were not rerun. The existing initialization workflow is the verified Logic/Workflow-adjacent business operation in this increment. Broader People/Projects workflow automation and Logic definitions remain deferred; the disabled top-level Workflow/Logic controls are not presented as operational proof. ## Protected CLI environment loading correction — 2026-10-14 The protected `bin/provision-target.php` entrypoint previously called `TargetRuntimeConfig::fromEnvironment()` without loading the repository's existing local operator configuration. This caused a local PowerShell invocation to fail before database connection with `Missing required runtime database setting: IDY_TARGET_DB_HOST`, even though the operator configuration file exists. The correction adds the allowlisted `App\Runtime\Bootstrap\LocalRuntimeEnvironment` loader. It loads only approved target database, staging identity, target runtime and Definition-publisher names from `.env.local` when those names are absent from the process environment. Explicit process variables remain authoritative. The web runtime does not load this file, no credentials are printed or persisted, and the existing staging database identity and publisher safeguards remain unchanged. The vocabulary CLI now uses the same helper. Local validation confirmed PHP syntax, the allowlist/precedence behavior and the target package composition. The current local operator environment still fails the non-secret preflight because `IDY_STAGING_DB_NAME` and `IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID` are not present in the process configuration; protected provisioning was not executed. An approved operator must supply those existing STAGING configuration values securely before the command can proceed. ## STAGING-only operational model — 2026-10-14 The current development phase now exposes the protected provisioning CLI only through `--database=staging`. The command uses the configured target database name as the STAGING identity when `IDY_STAGING_DB_NAME` is omitted, while retaining the non-production identity and selected-PDO checks. The internal generic target runtime and production identity preflight remain reusable abstractions for a future production requirement; no active production provisioning selector is exposed by the current operator command. Routine GitHub release deployment remains application-only: it does not run provisioning, migrations, Genesis, platform opening or publisher authority installation. Publisher reconciliation remains a separate protected operation through the existing installer and browser/CLI boundaries. ## Workflow and Logic surface increment — 2026-10-13 The authenticated Workflow and Logic status surfaces were added and deployed by GitHub Actions run 350 from commit `9d13c03b4dc87c91d70dcfc04d269b86134b5372`, release `IDY-TARGET-d683a6a2c4f521fde4fcf09cce7e4c9aad1bd98ffc69f9ff487acafc010bea29`. STAGING verification observed the existing Business initialization Workflow Definition (`Business initialization`, revision 1, active) and its persisted WorkflowExecution `de65213f-c5d6-42e4-b56a-e4c8d91edbc4` with status `succeeded` and one completed step. Workflow Definition and Execution inspection is now authorized through the same governed Business authority reconciliation used by the capability surface. The Logic surface correctly fails closed: the authenticated Principal does not have platform Definition inspection authority and no published supported Logic Definition is available in the current Business context. No Logic invocation control, fabricated result or stored-code execution is exposed. Creating and authorizing a platform Logic Definition remains the precise next dependency for a live Logic acceptance scenario. Notifications and Attentions remain disabled because their underlying contracts are not implemented. ## Governed Logic publication attempt — 2026-10-13 The governed Logic publication surface is implemented and deployed. It loads the deterministic data-defined `EQUAL` Logic Definition fixture from `minimal-project-status-logic.json`, invokes the existing platform-scoped `definition.publish` Operation, and uses `GenericLogicEvaluator` for actual evaluation. It does not write Definitions directly and does not execute stored code. The authenticated browser publication attempt returned `command_denied`. The existing narrow publisher-authority reconciliation route also failed closed because the current authenticated Principal is not the configured platform Definition publisher. No grant, Policy, Definition, revision or fake result was created. A platform operator must either authenticate as the configured publisher Principal or update the approved `IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID` configuration through the existing protected provisioning path before publication can succeed. Consequently, live Logic evaluation and Workflow-to-Logic execution remain unverified and correctly unavailable. The precise blocker is platform publisher identity/authority configuration, not evaluator implementation. ## Logic inspection authorization correction — 2026-10-14 The Logic inspection failure was caused by two inconsistent access decisions: `TargetRuntimeConfig::canViewDefinitions()` recognized the configured platform publisher, while `TargetHtmlBoundary::canViewDefinitions()` recognized only the separate inspection allowlist. The temporary same-request runtime evidence confirmed that the publisher setting was present through `getenv()` and matched the authenticated Principal; no hosting mismatch remained. The correction centralizes the shared publisher-or-explicit-allowlist decision in `DefinitionInspectionAccess` and uses it from both runtime configuration and the HTML boundary. It does not grant access to unrelated Principals and does not imply publication or Logic execution authority. Focused three-case regression coverage was added for publisher, allowlisted and unrelated Principals. ## Logic publication and evaluator verification — 2026-10-14 The deterministic Logic fixture was corrected to use the persisted Project Type as its typed subject, while retaining the canonical Definition identity `c2000000-0000-4000-8000-000000000001`, the `Logic` semantic role and the `EQUAL(status, active)` composition. GitHub Actions run 363, commit `632a7f64ce143e768126c22a69379dfa3cafa5c0`, deployed the correction to STAGING. The authenticated STAGING browser then published the Definition through the governed `definition.publish` Operation at revision 1. Evaluation through `GenericLogicEvaluator` returned `true` for the existing active Project `68ea1cdd-deaf-4859-8f4f-fa04b09f2a15` and `false` for the governed non-active acceptance Project `660c5111-0af2-4be5-bbbe-e03fc6678c64`. These are observed runtime results, not fabricated execution records. The Logic workspace initially had a presentation-only discovery mismatch: its published list recognized the historical `definition_kind` marker but not the canonical `semantic_role: Logic` marker. GitHub Actions run 364, commit `1dcf55b37b3433c272e1041de07f77d84018d8a7`, deployed that correction. The authenticated browser now lists the published Logic Definition and continues to expose the governed evaluator. Workflow-to-Logic execution remains unverified because no Workflow Definition has yet been configured to reference this published Logic Definition. ## Workflow-to-Logic integration verification — 2026-10-14 The existing Workflow contract supports a `condition` node whose expression is an exact `logic_reference` containing a Definition ID and positive revision. The bounded staging integration uses Workflow `c3000000-0000-4000-8000-000000000001`, revision 1, and references Logic Definition `c2000000-0000-4000-8000-000000000001`, revision 1. The Workflow is Business-scoped, triggered by the committed `object.updated` Event for the Project Type, and was persisted through the existing governed CREATE Operation path. GitHub Actions run 384, commit `9b27a9f7acfa6fd8fad3f8ad334b5f771e5323b6`, deployed the final execution-path and evidence corrections. Authenticated STAGING browser verification then observed: - Active Project `68ea1cdd-deaf-4859-8f4f-fa04b09f2a15` produced WorkflowExecution `28cc950a-4af3-46ec-8790-aad2804fe266`, status `succeeded`, one condition step, true branch, and persisted Logic evidence with the exact ID/revision. - Planned Project `660c5111-0af2-4be5-bbbe-e03fc6678c64` produced WorkflowExecution `87657040-5b00-47d1-ace9-f2edbea9c0b5`, status `failed`, one condition step, false branch, and persisted Logic evidence with the exact ID/revision. The Project edits used the normal governed update form. The committed `object.updated` Event was admitted, leased, interpreted, re-evaluated by the trusted Workflow Operation boundary and finalized through the existing Workflow execution pipeline. The condition evidence records `EQUAL`, the subject Object ID, the boolean result and Logic Definition revision; no comparison was recomputed in the Workflow runtime. The increment also corrected generic gaps discovered during verification: Workflow semantic validation now receives the object repository, trusted Workflow calls use Business runtime Operation identities, running-to-running steps validate the existing lease instead of attempting a new claim, and Workflow subject values are normalized to the evaluator's `{id, revision, value}` contract. Earlier failed attempts remain retained as `running` executions because the broader recovery/reconciliation mechanism was not implemented at the time of this acceptance evidence. They were not rewritten or deleted; the two fresh executions above are the acceptance evidence. The authenticated Workflow workspace now exposes the persisted Definition and execution evidence, but it is a bounded staging configuration surface rather than a general Workflow authoring UI. ## Workflow recovery and reconciliation implementation — 2026-10-14 The contract-defined bounded recovery slice is implemented in source: - Business-scoped `workflow_reconcile`, revision 1, is registered through the existing Operation resolver and trusted-handler registry; - expired `claimed` leases can be quarantined atomically as `reconciliation_required`, with lease metadata cleared and old-worker fencing preserved; - `fail`, `resume_safe` and `reconcile_command` are governed decisions with expected-revision and current-authority checks; - safe resume requires conclusive pure condition/end evidence and fails closed when local-command linkage or outcome evidence is missing; - known Command outcomes delegate to `CommandHandler::reconcile`; - synchronous runner failures are classified without treating uncertain exceptions as proof of no effect; and - release manifest/workflow checks were updated for the resulting 224-file target artifact. Evidence actually obtained: - The governed recovery/lease/finalization/idempotency and gap-regression coverage passed against local `IDY_TEST_IDY002`, including a legitimate second local Principal, negative safe-resume evidence and missing Command linkage cases. - The complete isolated PHPUnit suite passed with 492 tests and 2,982 assertions, with one pre-existing presentation warning, three skips and two PHPUnit deprecations. - Release package validation passed with 18 tests and 843 assertions. - GitHub Actions run 407 built and deployed commit `97d161dc5947f60310c049222d67f2056eaff9f9`; both build and staging deployment jobs completed successfully. - STAGING `/health` returned `runtime=target`, `status=boundary_ready`, `database_configured=true` and `database_connected=true`. - Prior authenticated STAGING acceptance directly verified expired-lease quarantine, explicit `fail`, stale revision rejection, ineligible recovery rejection, recovery evidence/provenance and existing active/planned Logic Workflow outcomes. - Isolated governed Operation regressions now verify unauthorized recovery denial, conclusive safe resume and explicit linked local-Command reconciliation. These are automated local evidence, not live STAGING evidence. The remaining live cases are unverified: same-Command browser replay, direct stale-worker/token submission, recovery denial through a second live Principal, live `resume_safe`, and live uncertain local-Command reconciliation. The available browser returned the Sign in surface after the latest deployment, and no second Principal or safe retained candidate was available. No direct database write, production deployment or duplicate Business/Principal/demo record was created. The current implementation deliberately does not add a general dispatcher, wake loop, scheduled recovery worker or blind local-command replay. Those remain separate future scopes. ## Core Object Presentation correction — 2026-10-14 Principal and Business persistence was already in the universal `objects` store; the implementation divergence was the presentation boundary. Business used a special detail page, Principal used `/profile`, and capability create routes rendered a separate record form. The correction keeps one generic Object and Presentation model: - platform-scoped Business roots and self-Principal Objects are authorized by explicit scope rules in the generic object reader; - Business context reconciliation provisions persisted Business-scoped View Definitions and Presentation Objects for the Business and Principal Types through governed Commands; - `/objects/{id}` uses the same Presentation Catalog/projector/renderer for Business, Principal and Business-owned Objects; - capability pages remain grouping/navigation surfaces and link to canonical `/objects` collections; legacy capability create/edit routes delegate to `/objects/create` and `/objects/{id}/edit`; - the canonical object form uses configured record fields and the existing generic Command mutation boundary. The focused generic-object and capability acceptance checks passed locally. The full PHPUnit result after this correction is recorded by the final build run; the pre-existing Presentation warning remains tracked separately. ## Batch 6 — Full PHPUnit failure classification and reconciliation Baseline evidence: - Branch `main`, HEAD `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`; the worktree was already dirty with 88 status entries before this batch and all existing changes were preserved. - Pinned PHP 8.3.33, PHPUnit 11.5.56 and MariaDB 10.5.26 were used. - Tests used only disposable local `IDY_TEST_IDY002`. The database was refreshed through `bin/refresh-test-database-from-staging.ps1`; STAGING was read-only and production was not contacted or mutated. Failure classification and corrections: | Failure group | Evidence and classification | Correction | | --- | --- | --- | | `ExternalActionAuthorizationTest`, `SendEmailOperationInvocationTest`, and `Idy004AccessTest` | Legacy fixtures supplied `target_type_ids` and stale Authority Grant revisions. Runtime correctly requires exact `target_type_references` and the current governance Type revision. Stale fixture contract. | Updated grants to governance revision 4 with exact Type references. | | `Idy008AAccessTest` | The fixture attempted to create current governance authority without installing the current persisted governance vocabulary. Fixture setup issue. | Installed `PlatformGovernanceVocabulary` before creating the grant. | | `GenericStoreAndGenesisTest` | Genesis/current governance installation now reaches revision 4; the assertion still expected revision 3. Stale expectation. | Updated the expected current revision to 4. | | `PrincipalAdmissionHardeningTest` | The expected 503 was initially 403 because the valid onboarding grant and platform policy led to a handler dependency failure: Initialization Type revisions were absent. Fail-closed runtime behavior was correct. | Installed `InitializationVocabulary` in the fixture; the rollback now reaches the injected event failure and returns 503. | | `BusinessCreationOperationHandlerTest` | Unit tests directly constructed a handler without its required repositories/resolver and asserted the retired `target_type_ids`/configuration-declaration contract. Stale test contract. | Added a governed disposable fixture with exact-reference dependencies and updated assertions to current exact Type references. | | Release and staging package tests | The source-defined resolver returned 228 target files and 202 staging files, while tests, workflows and current documentation still asserted 224/198. One manifest assertion also named the retired Capability projector. Release-contract drift. | Updated tests, workflow guards and current release documentation to 228/202 and the active persisted Presentation projector path. | Targeted evidence after correction: - Business creation and principal admission: 8 tests, 68 assertions, passing. - Target release manifest: 9 tests, 733 assertions, 1 skipped, passing. - Target release package: 7 tests, 66 assertions, passing. - Staging provisioning package: 2 tests, 26 assertions, passing. - External action: 6 tests, 9 assertions, passing. - CLI access: 11 tests, 41 assertions, passing. - Access: 14 tests, 87 assertions, 1 skipped, passing. - Send email: 6 tests, 43 assertions, passing. - Genesis/store: 23 tests, 52 assertions, passing. - Batch 5 baseline remained green: Logic 12/44; legacy demonstrator 10/55; Presentation 37/276 with 1 warning; Dispatch Lease 10/49; Finalization 27/137; Operation Foundation 73/141; Mutation 48/191 with 1 PHPUnit deprecation; Exact Reference Resolver 14/48. Final full-suite evidence: - PHPUnit completed with **527 tests, 3,237 assertions, 0 errors, 0 failures, 1 warning, 2 PHPUnit deprecations and 3 skipped tests** in 4:27.438. PHPUnit reported `OK, but there were issues!`. - The count differs from the earlier 534-test Batch 5 report because the live checked-in suite currently enumerated 527 tests; no failure or error remained in the completed run. - The warning is the known undefined `layout` access at `tests/Integration/Idy006BPresentationTest.php:297`. - The two PHPUnit deprecations remain non-failing notices; one is emitted by `Idy005MutationTest`. The three skips remain existing bounded/unsupported cases and were not broadened. - Workflow event and Presentation reconciliation diagnostics in the run are fail-closed test evidence for unauthorized or unavailable governed state, not PHPUnit failures. Verification: - PHP syntax checks passed for all changed PHP files. - `git diff --check` passed; Git emitted only existing line-ending normalization notices. - The architectural compliance audit passed with zero findings across 178 runtime files. - Final searches found no retired `AuthorityPolicy`, `DeterministicReasoner`, `minimal-project-status-logic.json` or fixture-driven runtime publication path. Test fixture publication names are confined to governed test setup. - No commit, push, deployment, STAGING mutation or production mutation occurred. The final worktree contains the preserved prior changes plus this batch's scoped fixture, release-contract and documentation updates. ## Batch 7 — Test integrity and quality closure Investigation established that the Batch 5 count of 534 and the Batch 6 count of 527 were not competing test-case/provider totals. The configured `phpunit.xml` suite included `tests/Unit` and `tests/Integration` but omitted `tests/Runtime`; explicit repository-path discovery included that directory. The seven missing methods were the three methods in `DashboardPresentationTest` and four methods in `RenderablePresentationTest`. The preserved Batch 5 output contains the Runtime grid failure, confirming that those tests were executed in the 534-test baseline. No tests were deleted, renamed or newly skipped. The remaining notice inventory was reproduced with PHPUnit 11.5.56: - The warning was an assertion-side access to optional `layout` data in `Idy006BPresentationTest`; the projector intentionally omits that key when no layout is present. - The two PHPUnit runner deprecations were doc-comment `@dataProvider` metadata in `GovernanceScopeTest` and `Idy005MutationTest`. - The three skips remain valid and bounded: the Windows account cannot create symlinks, the refreshed disposable snapshot does not contain Spearmint Design, and governed Policy activation/deactivation has not been assigned to an implemented stage. Scoped corrections: - Added `tests/Runtime` to the configured PHPUnit suite. - Migrated both data providers to PHPUnit's `#[DataProvider]` attribute. - Changed the Presentation assertion to verify omission of optional `layout` rather than reading a missing key. - Updated the Runtime grid fixture to represent a sized container surface and assert the documented `size-50` class for a three-column effective span. Production rendering was not changed. Validation was run sequentially against disposable local `IDY_TEST_IDY002` with inherited `IDY_TARGET_DB_*` variables cleared: | Scope | Result | | --- | --- | | Affected suites: GovernanceScope, Idy005 Mutation, Idy006B Presentation and Runtime Presentation | 98 tests, 517 assertions, 0 failures, 0 errors, 0 warnings, 0 PHPUnit deprecations | | Complete configured PHPUnit suite | **534 tests, 3,277 assertions, 0 failures, 0 errors, 0 warnings, 0 PHPUnit deprecations, 3 skipped** | The complete suite reported the same three explicit skip reasons listed above. Post-edit PHP syntax checks passed for all four changed PHP files, `git diff --check` passed, and the architectural compliance audit passed with zero findings across 178 scanned runtime files. A focused stale-contract search found no old DataProvider metadata, historical grid-style assertion or retired authority symbol in the changed Batch 7 files; the remaining `target_type_ids` occurrence is the existing generic relationship schema contract, not Authority Grant authorization. No commit, push, deployment, STAGING mutation or production mutation occurred. ## Batch 9 — Release candidate evidence closure The release scope was explicitly selected as the bounded Business-scoped Enquiry -> Qualification -> Project/Scoping demonstrator. The broader eight-capability platform, AI/provider integration, general scheduling, Stage 3D Type-revision work and production remain excluded. The live starting state was `main` at `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`, with 104 worktree status entries (89 tracked modifications and 15 untracked files), no staged files, PHP 8.3.33, PHPUnit 11.5.56 and the disposable `IDY_TEST_IDY002` procedure. Existing work was preserved; the three Products & Services/Stage 3D handoff documents remain outside the reviewed release source set. The complete source reconciliation retained only changes required by the approved runtime, release, configuration, documentation and verification boundary. The reviewed staged set contains 100 paths (85 modified, 11 added, 3 deleted and 1 rename), including the eight new runtime classes required by the active `app/Runtime/**/*.php` pattern and three exact-reference/composition regression tests. The active `release/target-release.json` resolved 228 public files. The separate operator-only `StagingProvisioningPackage` contract resolved 202 files; it was not conflated with the public package. The stale 171-file operational instructions were corrected to the verified 228-file public contract. `bin/target-check.php` reported a valid definition and 228 resolved files. Sequential local evidence against disposable `IDY_TEST_IDY002`: | Gate | Result | | --- | --- | | Release manifest/package/provisioning unit tests | 18 tests, 825 assertions, 0 failures, 0 errors, 1 valid skip | | Focused authorization, exact-reference, Presentation, mutation and workflow suites | 282 tests, 1,185 assertions, 0 failures, 0 errors, 1 valid skip | | Complete configured PHPUnit suite | **534 tests, 3,277 assertions, 0 failures, 0 errors, 3 valid skips** | | PHP syntax checks | 84 changed/staged PHP files, 0 failures | | `git diff --check` | PASS | | Architectural compliance audit | 178 runtime files, 0 findings | The three full-suite skips remain bounded and valid: Windows symlink capability, absent Spearmint Design in the disposable snapshot, and the unimplemented/unscheduled Policy activation lifecycle. Workflow exercises continued to emit the application-level fail-closed `Inspection is not authorized` diagnostics on STDERR; these are not PHPUnit warnings, failures or deprecations and were not suppressed. No PHPUnit warnings or deprecations were reported. No authorized STAGING deployment or exact GitHub artifact provenance was available in this batch. Accordingly, this evidence supports a **local candidate** only, not a STAGING-accepted candidate or production release. STAGING acceptance, exact GitHub-bound package digest/provenance, browser acceptance, rollback evidence and production operations remain external blockers. The reviewed source is authorized for a local commit only; no push, deployment, STAGING mutation or production mutation is authorized or claimed. ## Batch 10 — Push and GitHub provenance gate The exact Batch 9 candidate was pushed only after explicit authorization. The local and remote `main` references now both resolve to `29fa8d83eed23bb596025c1ccd7066020b8437f7`. The push was a normal non-force fast-forward from `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`. The three excluded Products & Services/Stage 3D handoff documents remain untouched and untracked. No reset, clean, stash, amend or force-push was performed. GitHub Actions run `39270017715` (run number 420) was created by the push. The `build-target-release` job completed successfully from the exact SHA; its checkout log records `ref: 29fa8d83eed23bb596025c1ccd7066020b8437f7`. The workflow wrote GitHub-bound provenance for repository `StuMayne74/Idiosyncrasy`, that commit SHA and build identity `github-actions/Build target release artifact/39270017715`. The build log reported the following verified public package evidence: | Evidence | Result | | --- | --- | | Resolved public files | **228** | | Release digest | `8d934f39d10ffcf535d7863c36ebc5fb6b637bc559a87b645c03299c0ca6a285` | | Release identity | `IDY-TARGET-8d934f39d10ffcf535d7863c36ebc5fb6b637bc559a87b645c03299c0ca6a285` | | GitHub artifact | `idy-target-release-29fa8d83eed23bb596025c1ccd7066020b8437f7` | | Artifact ID | `12195740392` | | Uploaded ZIP SHA-256 | `4b706d84927c24d327812d547719be44639799f20348865bdad323ab47d75cde` | | Artifact size | 424,742 bytes | The build job's package verification and artifact upload therefore establish the exact GitHub artifact and its provenance. The same push workflow automatically started `deploy-staging` (job `118119666866`) after the build; this was workflow-coupled behavior, not a separate manual deployment action. The job completed successfully and its log records the exact artifact download digest, exact repository/commit verification, `STAGING_DEPLOYMENT=ACTIVATED`, `HTTP_VERIFICATION=PASSED path=/health`, the release identity above and the same release digest. This establishes **PASS** for artifact deployment and the deployment helper's health check. This is not full STAGING acceptance. No browser journey, authenticated Enquiry -> Qualification -> Project/Scoping acceptance, Business-isolation check, governed mutation/expected-version check, negative authorization or stale-reference check, workflow dispatch/finalization check, rollback exercise or post-deployment reconciliation was run in this batch. Those items remain **NOT RUN** or **UNVERIFIED**. The deployment was an automatic consequence of the authorized push, not a separately approved STAGING deployment decision; the workflow's automatic STAGING coupling is a release-control risk requiring owner review before a future push. No production deployment or production mutation was performed or authorized. ## Batch 11 — STAGING acceptance preflight The read-only preflight reconfirmed local `HEAD` and `origin/main` at `29fa8d83eed23bb596025c1ccd7066020b8437f7`. The only worktree changes are the existing uncommitted Batch 10 update to this file and the three preserved, untracked Products & Services/Stage 3D handoff documents. No source, workflow or excluded document was changed in this batch. The GitHub Actions run `39270017715` remains completed successfully for the exact deployed SHA. Its published artifact remains `idy-target-release-29fa8d83eed23bb596025c1ccd7066020b8437f7`, with ZIP digest `4b706d84927c24d327812d547719be44639799f20348865bdad323ab47d75cde`. The deployment log records the deployed release identity `IDY-TARGET-8d934f39d10ffcf535d7863c36ebc5fb6b637bc559a87b645c03299c0ca6a285`, the matching release digest, and a successful target-runtime `/health` verification. A fresh direct workstation GET was not completed because Windows Schannel returned `CRYPT_E_REVOCATION_OFFLINE`; the CI deployment evidence is therefore the current verified health evidence, not a new interactive browser observation. The existing [HTTP acceptance README](../../tests/HttpAcceptance/README.md) and runner are local-only. The PowerShell launcher requires loopback `idiosyncrasy_dev` configuration, provisions only disposable `IDY_TEST_IDY002`, sets target variables to that disposable database, and starts a local PHP server at `127.0.0.1:8081`. `FixtureInstaller` runs migrations, resets foundation state, installs Genesis, vocabulary, demonstrator configuration and fixture identities. It is not safe to aim at STAGING and must not be reused against the deployed database. The existing `idy010` suite is the closest bounded Business-scoped browser journey. It covers authenticated Business selection, generic Presentation resolution, Enquiry creation, Qualification submission, exact revision and target rejection, cross-Business non-disclosure, CSRF, stale expected-version rejection, command evidence and no-GET-mutation. `idy009` covers the complete Enquiry -> Qualification -> reviewer Decision -> Project path, but it creates persistent records. Neither suite is a STAGING-safe read-only probe, and neither provides a separate STAGING authentication/configuration boundary. The local `capabilities` suite is read-only after its fixture reset but is also local-only. Workflow dispatch/finalization coverage exists in `Idy007CDispatchLeaseTest` and `Idy007CFinalizationTest` as disposable database integration tests; no remote STAGING workflow endpoint is exposed by the current acceptance runner. The deployment-control review found that `.github/workflows/build-target-release.yml` triggers on pushes to `main`; `deploy-staging` is conditioned directly on that push, depends on the build job, uses the `staging` environment and has `contents: read` plus `actions: read`. The environment declaration exists, but repository evidence does not establish that required reviewers or a deployment-branch restriction are configured; the observed Batch 10 job ran without an approval pause. The smallest proposed correction is to remove the push condition from `deploy-staging` and permit it only on an explicitly invoked, protected deployment workflow/job after artifact provenance is available. The `staging` environment must require an authorized reviewer; a later design may add an exact-SHA/artifact input if deployment of a previously built artifact rather than a same-run rebuild is required. No workflow change was made in Batch 11. STAGING product acceptance is **NOT RUN**. Authenticated STAGING credentials, the approved test Business/Principal pair, a record-isolation and cleanup plan, and an owner-authorized mutation window are prerequisites. No browser journey, persistent STAGING mutation, reconciliation, cleanup or production operation was performed. ## Batch 12 — Secure STAGING access readiness The repository-only readiness review found no confirmed secure operator mechanism for browser-level STAGING acceptance. The existing protected `staging` GitHub Actions environment supplies deployment and infrastructure diagnostic transport through environment variables and secrets such as the STAGING SSH values and target database values. The `staging-registration-diagnostic.yml` workflow is explicitly read-only for remote filesystem/database metadata and performs a GET-only `/register` diagnostic; it does not provide a Principal login credential, approved test Business identity, browser session or product acceptance client. The checked-in [staging deployment metadata](../../.deploy/idiosyncrasy-staging.json) contains non-secret SSH host/user/root and an external identity-file path. It is deployment metadata, not a browser-acceptance credential store. The documented external secrets/environment mechanisms likewise do not establish that an approved STAGING Principal credential or test identity exists. `IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID` is a non-secret configuration binding for an existing publisher and is not acceptance authorization. The existing [HTTP acceptance runner](../../tests/HttpAcceptance/run.php) remains intentionally local-only: its launcher requires loopback `idiosyncrasy_dev`, provisions/resets disposable `IDY_TEST_IDY002`, installs fixtures and starts `127.0.0.1:8081`. Its fixture password and identifiers are test data and must not be treated as current STAGING identities. The generic [HTTP client](../../tests/HttpAcceptance/Harness/HttpClient.php) supports a supplied base URL but no approved remote configuration boundary; adding one without an owner-approved credential and identity contract would create speculative remote execution infrastructure. Therefore the outcome is **BLOCKED — OPERATOR CONFIGURATION REQUIRED**. Missing or unverified prerequisites are: an authorized remote-capable client path, approved STAGING Principal credentials, the approved test Business and any reviewer identity required by the bounded journey, and operator confirmation that those values are available through a secure mechanism without entering chat or source control. No STAGING HTTP request, login, environment mutation, database operation, code change, commit or push was performed in Batch 12. ## Batch 13 — Secure operator handoff and readiness verification The authorized operator was asked to confirm readiness through the existing secure process without disclosing credentials, tokens, private keys, session cookies or secret configuration values. The operator confirmed only that the current authorization remains limited to read-only STAGING probes; it does not authorize login attempts, POST requests, mutations, cleanup, deployment or database operations. The following prerequisites remain **UNVERIFIED/BLOCKED**: - Approved STAGING Principal credential availability. - Approved test Business identity availability. - Approved reviewer identity availability. - Approved remote-capable HTTP/browser client availability and configuration. - Normal TLS certificate and revocation validation through that client. The operator did not confirm those prerequisites as available. No browser session, credential test, STAGING HTTP request, database access, environment mutation, workflow change, commit or push was performed. Historical CI deployment and `/health` evidence remains historical deployment evidence and does not establish current operator access or product acceptance. ## Batch 14 — STAGING deployment control remediation The repository-only review reconfirmed `main` and `origin/main` at `29fa8d83eed23bb596025c1ccd7066020b8437f7`, with the existing uncommitted status evidence and three excluded untracked documents preserved. Before this change, `build-target-release.yml` ran the build/provenance/artifact job on both `push` to `main` and `workflow_dispatch`, but its `deploy-staging` job was conditioned on every push to `main`. That made an ordinary push eligible for STAGING deployment. The workflow now retains build, package, provenance and artifact publication for pushes and manual dispatches, and adds a required `deploy_staging` boolean input defaulting to `false`. `deploy-staging` runs only when the workflow is explicitly dispatched with that input set to `true`. The manual run builds and publishes the artifact for its selected exact `github.sha`; the deployment job downloads that same-run SHA-named artifact and retains the existing manifest, release identity, 228-file count, GitHub provenance, repository/commit and package verification before invoking the deployment helper. No arbitrary latest-artifact or cross-run selection was introduced. The protected `staging` environment, existing non-overlapping concurrency group, `contents: read`/`actions: read` deployment permissions and deployment helper health verification remain in place. The build job has no `secrets.*` reference and no STAGING deployment secret. The existing read-only diagnostic workflow and production paths were not changed. Verification performed without STAGING or production access: | Check | Result | | --- | --- | | PHP syntax for changed `TargetReleasePackageTest.php` | **PASS** | | Repository-only workflow trigger/secret/provenance static validation | **PASS** | | `git diff --check` | **PASS** | | PHPUnit | **NOT RUN** — the repository bootstrap connects to and migrates the disposable test database, prohibited by this batch's no-database-operation boundary | | `bash -n bin/staging-deploy.sh` | **NOT RUN** — WSL has no installed distribution; the unchanged helper was statically checked for its required verification/health markers | | STAGING/production requests or operations | **NOT RUN** | This change cannot establish GitHub Environment enforcement from repository evidence. An authorized GitHub administrator must independently configure and verify required reviewers and deployment-branch restrictions for the `staging` environment, and must control who can dispatch with `deploy_staging=true`. No commit, push, deployment or environment mutation was performed. ## Batch 15 — Deployment protection verification and release gate The local Batch 14 workflow and regression-test implementation were rechecked without network access to STAGING or production. The workflow still proves the following locally: - `push` to `main` cannot satisfy the `deploy-staging` condition. - `workflow_dispatch` exposes a required `deploy_staging` boolean defaulting to `false`. - Deployment requires `workflow_dispatch`, `inputs.deploy_staging == true` and `needs: build-target-release`. - The deployment job uses the protected `staging` environment and retains the `idy-staging-deployment` concurrency group with `cancel-in-progress: false`. - The artifact name is bound to `github.sha`; the workflow contains no `workflow_run`, `run-id` or latest-artifact selection. - Re-verification checks the exact repository and commit provenance, release identity, digest, 228-file count, manifest and required package path. - Build steps retain PHP syntax checks, `target-check`, GitHub provenance generation, package creation/verification and artifact publication. - The build job has no `secrets.*` reference or STAGING deployment secret. The focused local workflow validator passed. PHP syntax for `TargetReleasePackageTest.php`, editor diagnostics for the changed files and `git diff --check` also passed. PHPUnit was not run because its bootstrap connects to and migrates the disposable test database, which is prohibited by this batch's no-database-operation boundary. No STAGING or production request, workflow dispatch, deployment, activation or persistent mutation was performed. Read-only GitHub Actions metadata confirmed the active workflow and the historical successful push run `39270017715` at `29fa8d83eed23bb596025c1ccd7066020b8437f7`. The available Actions interface does not expose environment reviewer, deployment-branch or bypass settings. An unauthenticated read-only request to the GitHub environment endpoint returned `404 Not Found`; this may represent absent access or a hidden administrative resource and does not establish that the `staging` environment is absent or unprotected. The release gate is therefore **BLOCKED pending authorized GitHub administrator verification**. The administrator must confirm, without changing the application workflow in this batch: 1. `staging` has at least one required reviewer or approved equivalent. 2. Deployment branches/tags are restricted to the intended release path. 3. The users/teams allowed to dispatch the workflow are appropriate. 4. No environment bypass setting or administrator path defeats the required approval for this deployment. The worktree remains at local and remote SHA `29fa8d83eed23bb596025c1ccd7066020b8437f7`, with the existing uncommitted Batch 10–14 evidence and three excluded untracked documents preserved. No commit, push, reset, clean or stash was performed. ## Batch 16 — GitHub Environment protection confirmation The available browser session could not open the repository's GitHub Environment settings page; GitHub returned its generic `Page not found` response. The unauthenticated GitHub Environment API request also returned `404 Not Found`. Neither response establishes that the Environment is absent or unprotected. An authorized-administrator attestation confirmed that the GitHub `staging` Environment exists. The same attestation did not confirm the remaining server-side controls: | Protection check | Result | Evidence | | --- | --- | --- | | `staging` Environment exists | **CONFIRMED** | Non-secret authorized-administrator attestation | | Required reviewers | **UNVERIFIED** | No administrative setting evidence supplied | | Deployment branch/tag restrictions | **UNVERIFIED** | No administrative setting evidence supplied | | Deployment initiation permissions | **UNVERIFIED** | No administrative setting evidence supplied | | Administrator/environment bypass control | **UNVERIFIED** | No administrative setting evidence supplied | | `deploy_staging` defaults false and requires explicit manual true | **CONFIRMED locally** | Workflow inspection and Batch 15 static validation; not server-side execution | No reviewer identities, screenshots, credentials, tokens or configuration values were collected or recorded. No workflow dispatch, STAGING or production request, deployment, setting change, commit, push, reset, clean or stash was performed. The release gate remains **BLOCKED**. An authorized GitHub administrator must inspect repository Settings -> Environments -> `staging` and attest that required reviewers, intended deployment branch/tag restrictions, deployment initiation permissions and bypass controls are all configured as required. ## Batch 17 — Final GitHub STAGING protection attestation The authorized-administrator attestation for the four outstanding controls was explicitly negative or inadequate: | Protection check | Result | Attestation | | --- | --- | --- | | Required reviewers | **NOT CONFIGURED** | `NO` | | Deployment branch/tag restrictions | **NOT CONFIGURED** | `NO` | | Deployment initiation restrictions | **NOT CONFIGURED** | `NO` | | Approval bypass control | **NOT CONFIGURED** | No native required-approval rule exists under the current configuration | The local workflow's explicit `workflow_dispatch` and `deploy_staging=true` condition remains confirmed, but that local condition does not provide server-side Environment approval. The release gate remains **BLOCKED** and the deployment-control remediation is not ready to commit or push. Before a separate commit/push decision, an authorized GitHub administrator must configure and verify: 1. At least one authorized required reviewer for the `staging` Environment. 2. Deployment branch/tag restrictions limited to the intended release path. 3. Appropriate repository Actions/workflow-dispatch permissions for deployment initiation. 4. The available control that prevents administrators from bypassing required Environment protection, followed by an independent verification that the approval gate is effective. No settings, code, workflow or repository state were changed in this batch. No workflow dispatch, deployment, STAGING/production request, commit, push, reset, clean or stash was performed. ## Batch 18 — Automatic deployment restoration assessment The owner-approved testing model was re-audited before implementation. The existing `bin/run-tests.ps1` runner: 1. invokes `bin/refresh-test-database-from-staging.ps1`; 2. reads the approved STAGING snapshot and recreates the local `IDY_TEST_IDY002` database; 3. configures the local `IDY_TEST_DB_*` process variables; 4. invokes the pinned PHP 8.3.33 runtime and PHPUnit 11.5.56. `tests/bootstrap.php` independently requires a MySQL-compatible `IDY_TEST_*` database and applies the runtime migrations before the configured PHPUnit suites run. This is the established local disposable-copy process; it was not replaced, duplicated or invoked in this batch. The current local workflow still has the Batch 14 manual-only condition: `deploy-staging` requires `workflow_dispatch` with `deploy_staging=true`. The current `origin/main`/GitHub workflow is different: its workflow file has no dispatch input and deploys on a push to `main`, but it also has no PHPUnit job. The remote workflow file was independently fetched from GitHub at SHA `bd25a9f7b7e51e1930d200b6f8e1e771037617ea`. No supported mechanism exists in the repository to make GitHub Actions either: - execute the established Windows/local STAGING-snapshot runner without accessing STAGING or production; or - consume a trustworthy, verifiable result produced by that local runner. The workflow has no approved self-hosted runner, snapshot artifact handoff, attestation contract or external check-consumption mechanism. Adding an independent GitHub Actions MariaDB service would violate the established database authority and owner-approved testing model. Treating a local result or committed evidence file as a GitHub test pass would not be trustworthy. Accordingly, no workflow change was authorized or made. Automatic push-to-`main` deployment cannot honestly be restored as a full test-gated deployment within this batch's constraints. Restoring only the push condition while omitting the required PHPUnit gate would violate the deployment policy. A future implementation requires the smallest additional owner-approved mechanism that preserves the local runner while providing a trustworthy GitHub deployment prerequisite; no such mechanism is currently documented or present. No PHPUnit run, STAGING snapshot refresh, STAGING/production database access, workflow dispatch, deployment, commit or push occurred in this batch. ## Batch 19 — Established automatic STAGING deployment restored The actual worktree was rechecked at local and remote SHA `29fa8d83eed23bb596025c1ccd7066020b8437f7`. The local workflow differed from `origin/main` only in the Batch 14 `deploy_staging` dispatch input and the manual-only `deploy-staging` condition. The remote workflow and historical GitHub Actions run `39270017715` confirm the previously working policy: pushes to `main` build and verify the exact release, then automatically run the protected STAGING deployment job. That run successfully deployed the exact SHA and passed the deployment helper's `/health` check. The local deviation was restored without introducing a new pipeline: - `workflow_dispatch` remains available without a deployment input for non-deploying build/package diagnostics. - `deploy-staging` again requires `github.event_name == 'push' && github.ref == 'refs/heads/main'`. - The deployment job still depends on `build-target-release`. - The same-run SHA-named artifact, manifest/package verification, release identity, digest, 228-file count, GitHub repository/commit provenance, deployment helper, protected `staging` environment, least-privilege permissions and serialised concurrency are unchanged. - STAGING SSH credentials remain scoped only to the deployment job. The focused workflow regression assertion now verifies automatic push deployment and that manual dispatch cannot enter `deploy-staging`. The established local testing model remains unchanged: the approved `bin/run-tests.ps1` process refreshes the disposable local database from the approved STAGING snapshot and runs the pinned PHPUnit suite locally. The GitHub workflow's actual checks remain its existing PHP validation, `target-check`, GitHub provenance generation, package creation/verification and exact artifact publication; the local PHPUnit result is not represented as a GitHub-executed test or fabricated attestation. The native GitHub Environment approval controls remain a separate documented security limitation and were not changed. They do not alter restoration of the established automatic deployment policy, but repository administrators could still change workflow or repository behavior. No STAGING/production database access, workflow dispatch, deployment, activation, commit or push occurred. The three excluded proposal/Stage 3D documents and all unrelated worktree changes remain preserved. ## Batch 20 — Bounded legacy AuthorityGrant contract migration — 2026-10-18 The STAGING inspection failure was established as persisted contract drift, not an authorization-reader defect. The affected legacy AuthorityGrant Objects are bound to AuthorityGrant Type revision 1 and carry `target_type_ids`; the current AuthorityGrant Type revision 4 and runtime require exact `target_type_references` containing persisted Type Object identity and revision. The existing authorized reader therefore fails closed when it cannot resolve an accepted exact Type reference. The implementation adds a bounded, staging-guarded operator path through the existing generic Command, Object revision, provenance and event mechanisms. `object.rebind_type` is not a normal grant-management API: it is accepted only for this migration authorization operation, only for an AuthorityGrant Type, only when an active Business Administrator grant with `object.update` and an allowing Policy authorizes the target, and only with an explicit expected Object revision. The migration: 1. requires the exact legacy grant identity, Business and current Object revision; 2. reads each persisted legacy Type identity and all valid Type Object history revisions; 3. fails closed for malformed, duplicate, missing or invalid Type identities; 4. removes `target_type_ids`, writes exact Type references and rebinds the same grant identity to the current AuthorityGrant Type revision; and 5. appends one governed Object revision plus the normal Command, Event and Provenance evidence. Local evidence against disposable `IDY_TEST_IDY002` with PHP 8.3.33 and PHPUnit 11.5.56: | Suite | Result | |---|---| | `AuthorityGrantContractMigrationTest` | 4 tests, 33 assertions, 0 failures, 0 errors | | `AuthorityGrantContractMigrationTest`, `ExactObjectReferenceResolverTest`, `Idy006BPresentationTest`, `DashboardPresentationIntegrationTest` | 55 tests, 357 assertions, 0 failures, 0 errors | PHP syntax checks and `git diff --check` passed. No STAGING or production database mutation was executed. The new CLI does not run during deployment; after the code is released, an authorized operator must invoke it separately for each confirmed legacy grant with the exact Business, grant identity and expected current revision. Read-only inspection must then verify authorized Business/Dashboard reads and preserved unauthorized and cross-Business denials before Presentation graph repair begins. ## Batch 21 — Obsolete release count gate removed — 2026-10-20 Push `afc83ad` passed the target-release build and package publication job, but the automatic STAGING deployment job stopped during downloaded-artifact verification because the package had changed from the historical reviewed total of 228 files. The package remained valid: canonical manifest identity, per-file byte and SHA-256 checks, GitHub provenance and required target paths all verified locally, and no STAGING mutation occurred. The obsolete fixed total-file-count assertions were removed from the build and read-only diagnostic workflows and their deployment tests. Manifest metadata remains informational, while manifest-declared paths, per-file integrity, provenance, release identity, required files and target health remain enforced. The package was reproduced locally with the pinned PHP runtime and verified through the unchanged canonical package verifier. ## Batch 22 — Capability Definition Type revision-4 review — 2026-10-20 The Capability Definition Type retains its historical revision-3 descriptor without `navigation_order` and appends the current `navigation_order` contract as revision 4. The canonical descriptor digests are: - revision 3: `894ef3c523d5394ee1d90840ca751d2a1c37a90d7261498c2874135c1391267d`; - revision 4: `7ede8432e75229b5d7fddeb1068fb3bd14f8519b943a2753182c6a2930d43726`. The local migration uses the existing Type Object revision mechanism, coordination lock, expected-version enforcement, validation, revision history and provenance. It accepts only the exact revision-3 predecessor, is idempotent when revision 4 is already current, preserves revision-3 Definition references, and does not rebind existing Definitions or alter `platform.type_revision`. The protected vocabulary reconciliation accepts the exact historical predecessor before the append. Local evidence against disposable `IDY_TEST_IDY002` with PHP 8.3.33 and PHPUnit 11.5.56: | Suite | Result | |---|---| | Capability revision, vocabulary and Person/Organisation regressions | 38 tests, 481 assertions, 0 failures, 0 errors, 0 warnings | | Legacy Dashboard presentation integration | 3 failures in the unchanged fixture path; standard application provisioning is defined but not invoked by `FixtureInstaller` | PHP syntax checks, canonical hash assertions and `git diff --check` passed. The revision-4 change remains local review evidence only: it has not been committed, deployed, reconciled or executed against STAGING or production. An authorized rollout must first verify the exact persisted revision-3 predecessor and dependent Definition inventory, then deploy through the protected workflow and run the approved vocabulary reconciliation. ## Batch 23 — Stage 3D partial owner decision record — 2026-10-21 The project owner supplied a partial Stage 3D decision record. The approved-in-principle direction preserves Presentation/View Definition Type revision 1 and appends revision 2 with optional `target_type_revision`, preserves Capability Definition Type revision 3 and appends revision 4, excludes the separate Presentation Object Type, and prohibits historical descriptor rewrites or automatic Definition/View rebinding. The intended dedicated Operation is `platform.type_revision`, candidate ID `9f4f6b8c-3d2e-4f10-8a11-223344556702`, revision 1, with trusted handler key `platform.type-revision`. The proposed exact Type Object allowlist contains only the Presentation/View Definition Type `8a4f6b8c-3d2e-4f10-8a11-223344556690` and Capability Definition Type `7a4f6b8c-3d2e-4f10-8a11-223344556690`. Candidate Type-revision AuthorityGrant and Policy IDs are `b3000000-0000-4000-8000-000000000003` and `b3000000-0000-4000-8000-000000000004`. The direction requires a separate grant and Policy, the existing governed Operation/Command/evidence pipeline, commit-time authorization and expected-version/hash revalidation, coordination and target locking, and two independently atomic idempotent Commands. The intended existing-target invocation is a separate bounded authenticated CLI based on the existing `reconcile-foundation.php` safeguards. No Operation, grant, Policy or Principal has been installed or authorized by this record. The following remain unresolved: decision owner/delegated authority and governance reference; trusted handler/release owner; collision-checked final identifiers; designated Type-revision Principal and any Definition Publisher Principal reuse; final CLI and credential contract; event/reason-code names; diagnostic detail and protected workflow; and any additional conditions. This is documentation evidence only. No tests, diagnostic, authentication, deployment, STAGING/production mutation or Type-revision execution occurred. Source-controlled hashes and candidate identifiers remain unverified against persisted STAGING state. **Stage 3D remains PLAN ONLY / NO-GO FOR BUILD.** ## Project transition browser verification The declared `from_state_id` submission correction was deployed in protected release run `39921964569` (run 511), commit `609e16cd280ca171ac29c6bfdd4bed84cfecf802`. The deployment package and `deploy-staging` job both completed successfully. Authenticated browser verification was performed on `https://platform-staging.idiosyncrasy.co.uk/` using the existing Spearmint Design business and Project `660c5111-0af2-4be5-bbbe-e03fc6678c64`. Submitting the persisted `planned -> active` action succeeded and opened Command evidence: - Command `2781e692-d770-4c1f-b2ee-7ee4af4c7383`: `settled`. - Outcome: `transition_committed`; expected version `2`, result version `3`. - Transition: `496c3f97-d0cc-46b6-abf5-25e93c99ee47` -> `f8be0edd-165c-4481-847d-e5599ea9cf6a`. - Action execution and attempt: `settled`. - Outcome: `succeeded`, reason `transition_committed`. - Provenance: principal `c92ebd13-d57e-48c8-b4df-f5171598e91a`, Business `a20d5b62-078c-4ef4-b0ce-41027f9bc275`, source `target_html`. Reloading the exact Project detail URL preserved status `Active`, version `3`, the persisted `Change project status` action, and the configured Milestone and People relationship actions. This completes the browser verification of the corrected Project lifecycle submission path. ## Batch 25 — Shared body grid and direct Presentation manipulation — 2026-10-22 The fixed Presentation layout mechanism is now recorded across the UI implementation references. Every authenticated main-body Presentation surface, including Dashboard, capability and ordinary Object views, uses the shared six-column grid at wider viewports and collapses to one column responsively. The persisted minimum/default Presentation Object span remains two columns. Layout editing has one mechanism only: the shared `Edit layout` / `Save layout` interaction, a top-right drag handle for repositioning and a bottom-right resize handle for changing width and height. Per-Presentation-Object action buttons are not part of the contract. Position and size continue to persist through the governed user-preference Object route with exact references and optimistic version checks. Changed implementation surfaces: - shared authenticated `.content` and generic body grid CSS; - generic Presentation renderer handle-only editing markup; - drag/resize client with the removed per-object button-control path; - synchronized target browser artifact and cache-busting asset references; - Presentation renderer regression assertions and UI/reference documentation. Focused evidence: | Check | Result | |---|---| | `DashboardPresentationTest` | 6 tests, 34 assertions, 0 failures, 0 errors | | `Idy006BPresentationTest` | 37 tests, 282 assertions, 0 failures, 0 errors | | PHP lint, Node syntax checks and `git diff --check` | Passed | The integration test emitted the existing non-fatal denied inspection diagnostic to STDERR after PHPUnit reported success; the PHPUnit result itself was **37/37 passing**. STAGING deployment and authenticated browser verification remain the final release checks for this batch. ## Batch 25 — Revision-1 Presentation blocker and honest empty state — 2026-10-21 The existing Presentation runtime can render a useful initial Presentation without appending Presentation/View Definition Type revision 2. Focused local evidence against the already-provisioned test database passed: | Suite | Result | |---|---| | `Idy006BPresentationTest` | 37 tests, 276 assertions, 0 failures, 0 errors, 1 warning | | `DashboardPresentationTest` | 4 tests, 29 assertions, 0 failures, 0 errors | | `DashboardPresentationIntegrationTest::testDashboardUsesPersistedCompositionAndCommonRenderablePresentation` | 1 test, 10 assertions, 0 failures, 0 errors | The current protected STAGING diagnostic run `39615620287` established that the Presentation Object Type exists at revision 1, the Business has the exact Dashboard reference `87c1954c-7810-445c-85dd-1bdc96a6f10f` at revision 2, the Dashboard, Overview and Overview title Presentation Objects exist, and the active inspection grant includes the Presentation Object Type. The authenticated browser nevertheless rendered the Dashboard title with an empty persisted element tree and only the Dashboard navigation entry. The actual blocker is therefore not Presentation Type revision 2. The current runtime's exact governed Presentation Object traversal is suppressing the STAGING child branches because their persisted reference/value/authorization compatibility has not been proven. The existing projector must not be weakened with a permissive fallback or synthetic Business data. The new Presentation template now renders a truthful, accessible empty state instead of a blank surface when no authorized persisted elements survive projection. The protected Stage 3D Type diagnostic implementation remains the bounded next evidence route. Its sources are still uncommitted and have not been executed against STAGING. No Type revision, grant, Policy, Principal, Presentation Object, Business binding or consumer was mutated. **Stage 3D remains PLAN ONLY / NO-GO FOR BUILD.** ## Batch 24 — Stage 3D read-only diagnostic implementation — 2026-10-21 The protected STAGING registration diagnostic now has a bounded Type-revision inspection slice. The new diagnostic receives the exact checked-out source through the protected workflow's existing SSH helper, opens the verified STAGING database in a read-only transaction and performs only prepared `SELECT` queries. It does not use the empty-target provisioning route, runtime migration, reconciliation, repository mutation or Type-revision authority. For the two approved target Type Object IDs only, the diagnostic reports existence, current Object version, Type-of-Type identity, scope, the persisted current descriptor and canonical hash when safely available, retained history versions and hashes, revision-level `command_id`/`provenance_ref` state, bounded related evidence references, bounded dependency identifiers/counts and comparison against the proposed historical and target hashes. Comparison is fail-closed: - `MATCH_HISTORICAL` requires the persisted current hash and version to match the historical pair and complete retained history to prove that pair. - `MATCH_CURRENT` additionally requires complete retained history to prove the historical pair and the target pair at their exact versions. - `MISMATCH` reports known persisted identity, scope, version or hash conflict. - `UNVERIFIABLE` reports missing objects, malformed descriptors, incomplete or truncated history, unavailable required schema/evidence or other inability to prove the comparison. History, dependencies, evidence references and descriptor output are bounded. Sensitive-looking descriptor fields are redacted in output while canonical hashes are calculated from the unredacted persisted descriptor. Missing history or evidence is never inferred from source-controlled fixtures. Focused local evidence: | Check | Result | |---|---| | `StagingTypeRevisionDiagnosticTest` against already-provisioned local test database | 9 tests, 23 assertions, 0 failures, 0 errors | | PHP syntax checks for diagnostic class, probe and test | Passed | | Protected shell syntax check | Passed with Git Bash | | Read-only source-token safety check | Passed | | `git diff --check` | Passed | The protected workflow has not been run for this change. No automated test connected to STAGING, no diagnostic was executed against STAGING, and no persisted Type revision, grant, Policy, Principal, Definition binding or consumer was changed. Actual STAGING Type state therefore remains **UNVERIFIABLE** pending separately authorized protected workflow execution. **Stage 3D remains PLAN ONLY / NO-GO FOR BUILD.** ## Principal / Business model clarification — 2026-10-28 **Status: DOCUMENTATION ONLY; PROPOSED CLARIFICATION PENDING PROJECT-OWNER APPROVAL.** Stu directed that no additional Principal, Membership or AuthorityGrant records be created, and that the Person/Principal/Business/Relationship/Membership/Authority/Account model be reconciled with existing decisions first. The reconciliation is recorded in [identity and governance](../architecture/identity-and-governance.md#concept-map-person-principal-business-relationship-membership-authority-and-account). It maps each concept to existing mechanisms, lists what is already settled, and records five unresolved owner questions, the governed presentation route, and the temporary restrictions with revisit conditions. Evidence and limits: - Read-only STAGING inspection showed the Principal and Business `/objects/{id}` pages are minimal (`display_name`/`status` via the core-object profile, revision 1). Their content was not changed. - `SpearmintDemoPopulationService` populates no Principal, Membership, Grant or Policy. No demo-data, schema, identity or authority state was modified. - The Stuart case is derived from `BusinessCreationOperationHandler`, the installation contracts and earlier status evidence. Live Membership/Grant/Policy objects were not re-read. - `bin/build-spearmint-capabilities.php` hardcodes a publisher Principal ID labelled as from a staging snapshot, which differs from the currently authenticated operator Principal. It is historical tooling, not authority, and has not been reconciled. **Smallest safe next step, for approval:** approve (or amend) the concept map and rule on unresolved questions 1-2 (Person-Principal association; Person-Business relationship Types). Until then no identity or authority data changes and the Principal/Business presentation stays minimal.