diff --git a/.github/workflows/release-checks.yml b/.github/workflows/release-checks.yml new file mode 100644 index 0000000..1b09165 --- /dev/null +++ b/.github/workflows/release-checks.yml @@ -0,0 +1,40 @@ +name: Cumulus release checks + +on: + pull_request: + push: + branches: + - main + +concurrency: + group: release-checks-${{ github.ref }} + cancel-in-progress: true + +permissions: + contents: read + +jobs: + verify: + runs-on: ubuntu-latest + timeout-minutes: 30 + steps: + - name: Check out the reviewed commit + uses: actions/checkout@v4 + + - name: Use Node.js 24 + uses: actions/setup-node@v4 + with: + node-version: 24 + cache: npm + + - name: Install exact dependencies + run: npm ci + + - name: Install Chromium for public browser checks + run: npx playwright install --with-deps chromium + + - name: Run the complete public release checks + run: npm run verify + + - name: Run desktop and mobile browser checks + run: npm run test:e2e diff --git a/README.md b/README.md index 25c099e..33a15c8 100644 --- a/README.md +++ b/README.md @@ -12,6 +12,7 @@ This repository defines the public application and its public-safe integration c - `main` is the authorized production branch. The pre-redesign Git state remains preserved on an archive branch, and the two design branches remain reviewable. - Resend Contacts, a dedicated Segment, and an opt-out-by-default Topic are the notification preference store and delivery boundary. Keys and provider-account identifiers stay in the deployment control plane, not this repository. - Production notification publishing intentionally fails closed until `NOTIFICATION_POSTAL_ADDRESS` and `RESEND_WEBHOOK_SECRET` are configured and a controlled sign-in, receipt, unsubscribe, and suppression lifecycle is verified. +- Post content lives in the validated `src/content/posts.json` catalog. A private remote publisher may update that single public-safe file through a reviewed GitHub pull request; publisher credentials and draft state never belong in this repository. See [Vercel cutover](docs/vercel-cutover.md) for the gate sequence and [private overlay](docs/private-overlay.md) for the public/private split. @@ -97,6 +98,8 @@ The production workflow is: 6. Verify the exact production deployment, bundled font delivery, direct-route refreshes, static metadata, sitemap, 404 behavior, and domain alias. 7. Verify sign-in and one controlled Resend lifecycle only after the truthful postal address and webhook signing secret are present. +The optional private remote publisher keeps daily publishing off the operator's computer. It shows a live deterministic preview while the owner types; one Publish action then turns the supplied text into the existing JSON schema, creates a review branch, waits for checks and the exact Vercel preview commit, merges only that reviewed commit, verifies the matching production deployment and public route, and calls the notification endpoint in dry-run mode before any live send. Author-supplied HTTPS links are preserved and validated; automation cannot invent a source URL. Its Sites source, D1 publication history, owner identity, and GitHub/Vercel credentials are private operational material. The publisher does not send the post text to an AI service. + Do not create a replacement Vercel project merely to deploy this branch. Retaining the same external Vercel project and Git integration is what preserves its project-level settings and domain association. Re-verify the existing project and domain immediately before cutover because a repository commit cannot prove current provider state. ## Product behavior @@ -109,6 +112,8 @@ The public experience is intentionally narrow: - a preference/unsubscribe path that does not require a content account; - a privileged, server-side publication notification trigger. +Published and draft entries are loaded from `src/content/posts.json`. The application validates slugs, dates, approved project/category pairs, Editorial entries, tags, dither variants, related links, body structure, and exactly one featured post. Reading time remains calculated in application code. New entries use `recent`; content automation cannot replace the featured post. + Consent, idempotency, unsubscribe behavior, and operational delivery rules are specified in [notifications](docs/notifications.md). Reader-facing notification data boundaries and the manual correction/deletion contact are published at `/privacy`. diff --git a/docs/notifications.md b/docs/notifications.md index aa26e49..8e3a773 100644 --- a/docs/notifications.md +++ b/docs/notifications.md @@ -30,6 +30,8 @@ The Segment and Topic IDs are private deployment configuration. Cumulus checks b `POST /api/notifications/publish` requires `NOTIFICATION_PUBLISH_SECRET`. It builds a deterministic Broadcast name and idempotency key from the immutable post slug, checks for an existing exact-content Broadcast, and refuses content conflicts. Resend Broadcasts supply the recipient-specific unsubscribe URL; the HTML presents it as a clear footer button and the plain-text part includes the same action. Both HTML and text include the truthful configured postal address. +An external publisher must not call this endpoint until the reviewed commit is on `main`, Vercel reports a successful Production deployment for that exact commit, and the public `/logs/{slug}` route passes a smoke check. It must call dry-run mode first. A failed preview, merge, deployment, public-route check, or dry run blocks delivery. A later retry uses the same slug, so the endpoint's existing idempotency protection prevents a second broadcast. + The authenticated Resend webhook accepts only bounced, complained, and suppressed events. It verifies the Svix signature over the raw body, normalizes unique recipients, and opts the matching Cumulus Topic out. Unsupported events are acknowledged and ignored; provider failures return a retryable error. ## Environment contract diff --git a/docs/private-overlay.md b/docs/private-overlay.md index de31ece..44a5848 100644 --- a/docs/private-overlay.md +++ b/docs/private-overlay.md @@ -8,5 +8,8 @@ Keep the following directly in Vercel, Resend, an approved secret manager, or a - Vercel project/team identifiers, deployment URLs, tokens, environment values, domain evidence, and rollback records; - truthful postal address and independent publication/session signing secrets; - real recipient addresses, support requests, and lifecycle evidence. +- private publisher source and deployment access, Sites D1 drafts and workflow state, owner allowlists, repository-scoped GitHub write credentials, Vercel monitoring credentials, and publisher audit evidence. + +The remote publisher may write only the public-safe `src/content/posts.json` file through a reviewed pull request. Its runtime secrets must remain in the private Sites environment. The public repository may contain the content schema, validation, remote CI, and documentation, but not the publisher's credentials, private deployment URL, drafts, or provider identifiers. `NEXT_PUBLIC_SITE_URL` is deliberately browser-visible. Every notification credential is server-only. Synthetic examples such as `reader@example.com` are safe; sanitized-looking copies of live data are not. Outlook is outside the Cumulus system and remains untouched. diff --git a/docs/public-release.md b/docs/public-release.md index adfd55d..826b5d5 100644 --- a/docs/public-release.md +++ b/docs/public-release.md @@ -18,6 +18,7 @@ Use this checklist for Cumulus 0.0.8 before pushing either design branch, publis - [ ] `RESEND_API_KEY`, `RESEND_WEBHOOK_SECRET`, Resend Segment/Topic IDs, optional `GITHUB_ACCESS_TOKEN`, `NOTIFICATION_POSTAL_ADDRESS`, `NOTIFICATION_PUBLISH_SECRET`, and `NOTIFICATION_UNSUBSCRIBE_SECRET` remain outside public files and browser bundles. - [ ] If configured, `GITHUB_ACCESS_TOKEN` belongs to a separate least-privilege viewer identity with no private-repository access; otherwise the endpoint uses only the fixed public profile. In both cases, the endpoint matches the public profile. - [ ] Test fixtures use synthetic identities. +- [ ] No private publisher source, draft, owner email, Sites URL, or publisher provider credential is tracked. ## 3. Brand and third-party material @@ -47,6 +48,8 @@ npm run test:e2e - [ ] Any skipped or environment-dependent test is named in the handoff and is not reported as passed. - [ ] Responsive behavior was checked at 320 px, 390 px, tablet, desktop, and wide desktop widths. - [ ] Keyboard, visible focus, screen-reader status, and reduced-motion paths were checked. +- [ ] The JSON post catalog accepts variable post totals, short Editorial posts, and valid approved dither variants while rejecting duplicate slugs and unsafe source links. +- [ ] Routes, archive search, homepage sections, metadata, canonical URLs, sitemap, table of contents, and related-post fallback include a synthetic new post. ## 5. Notification behavior @@ -72,6 +75,9 @@ npm run test:e2e - [ ] Main replacement or merge has separate explicit approval. - [ ] Production promotion and live domain cutover have separate explicit approval. - [ ] The prior production deployment remains available for rollback until post-cutover checks pass. +- [ ] If the private remote publisher is used, its reviewed commit matches the successful preview commit and `main` has not changed since preview creation. +- [ ] The matching Production deployment and `/logs/{slug}` were verified before a notification dry run. +- [ ] Live publisher notifications remain disabled until a synthetic preview and controlled subscriber lifecycle pass. ## 7. Public handoff diff --git a/playwright.config.ts b/playwright.config.ts index 9ece480..cb19554 100644 --- a/playwright.config.ts +++ b/playwright.config.ts @@ -1,5 +1,8 @@ import { defineConfig, devices } from "@playwright/test"; +const localChromiumExecutable = + process.env.PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH; + export default defineConfig({ testDir: "./tests/e2e", fullyParallel: true, @@ -10,6 +13,9 @@ export default defineConfig({ reporter: [["list"], ["html", { open: "never" }]], use: { baseURL: process.env.PLAYWRIGHT_BASE_URL ?? "http://127.0.0.1:4173", + launchOptions: localChromiumExecutable + ? { executablePath: localChromiumExecutable } + : undefined, trace: "retain-on-failure", screenshot: "only-on-failure", }, diff --git a/scripts/generate-static-routes.mjs b/scripts/generate-static-routes.mjs index 874754d..cfcf01d 100644 --- a/scripts/generate-static-routes.mjs +++ b/scripts/generate-static-routes.mjs @@ -2,11 +2,12 @@ import { mkdir, readFile, writeFile } from "node:fs/promises"; import { dirname, join } from "node:path"; import { URL } from "node:url"; -import { FOCUSED_POSTS as publishedPosts } from "../src/content/focused-posts.ts"; +import posts from "../src/content/posts.json" with { type: "json" }; const DIST = new URL("../dist/", import.meta.url); const ORIGIN = "https://cumulush.com"; const template = await readFile(new URL("index.html", DIST), "utf8"); +const publishedPosts = posts.filter((post) => post.status === "published"); function escapeHtml(value) { return value diff --git a/src/content/focused-posts.ts b/src/content/focused-posts.ts index b0729aa..7efaa01 100644 --- a/src/content/focused-posts.ts +++ b/src/content/focused-posts.ts @@ -1,1146 +1,5 @@ -import type { Post } from "./post-types.js"; - -type PublishedPost = Omit; - export const FIRST_PARTY_JOURNAL_NOTICE = { label: "Maintainer-authored first-party journal", detail: "Approved product reasoning from private evidence; no public-source, deployment, or production verification is claimed.", } as const; - -const JOURNAL_POSTS: readonly PublishedPost[] = [ - { - title: "Organization-Scoped Registers Without Spreadsheet Amnesia", - slug: "requisia-organization-scoped-registers", - excerpt: - "Requisia treats the familiar workbook as an exchange surface around an organization-scoped register, preserving identity, field meaning, and revision history when the table changes shape.", - status: "published", - date: "2026-07-17", - category: "Requisia", - project: "requisia", - tags: ["Register identity", "Schema revisions", "Controlled fields"], - placement: "featured", - visual: { - variant: "record-lattice", - alt: "Animated dither lattice in which register rows keep their identity while columns shift", - }, - body: [ - { - heading: "A table can remember more than its cells", - paragraphs: [ - "Procurement work often begins in a workbook because a table is quick to read, easy to circulate, and flexible enough for an unexpected field. The weakness appears later: two rows can look identical while representing different obligations, and a renamed column can quietly change the meaning of years of history. Requisia approaches that problem by treating the register as the durable product object and the workbook as one useful view of it. That distinction preserves the familiarity of rows and columns without asking the file to carry every rule by itself.", - "The public account here is limited to concepts approved from private implementation and product contracts: fields, records, templates, and the selected Current workbook are separate concerns. A record keeps a stable identity while visible values change; a field gives a column explicit meaning; a template shapes an exchange format; and Current points to an accepted version. That separation supports the design discussion, but an anonymous reader cannot reproduce the underlying implementation observation. It proves nothing about production organization setup, historical migration, or a customer workflow passing live verification.", - ], - }, - { - heading: "Organization scope comes before the row", - paragraphs: [ - "A register row is not meaningful in isolation. The same supplier name, reference number, or status label can legitimately exist in two organizations with different histories and owners. Requisia therefore makes organization scope part of the server-side decision before a record is read or changed. The browser may name the record a person wants to open, but it cannot decide which organization owns it. This ordering matters because a perfectly valid identifier from one workspace must remain useless in another, even when both people arrived through the same visual interface.", - "The model also avoids a hidden universal workspace. Defaults feel convenient during development, yet they turn missing context into accidental access when a request reaches the wrong path. A scoped register instead requires the application to resolve the signed-in actor, organization, register, and permitted action from trusted state. That is a design boundary, not a claim that isolation has been proven under production traffic. Public confidence would require representative sessions, cross-organization negative tests, role changes, and provider evidence that is deliberately outside this journal entry.", - ], - }, - { - heading: "Fields and revisions make collisions visible", - paragraphs: [ - "When a field is only a label above a cell, every importer and screen can interpret it differently. Requisia gives fields a more serious job: they connect the application property to the workbook column and can carry controlled choices or other validation expectations. A field change is therefore a schema decision rather than a cosmetic edit. That makes it possible to explain why an old workbook needs review, why an unfamiliar value was rejected, or why a column cannot simply vanish while records still depend on its meaning.", - "This separation also clarifies permissions. Editing a record value, changing the register schema, hiding a field, deleting a record, and permanently purging a field do not have to be the same authority. A person trusted to update an order status need not be able to redefine the status vocabulary for everyone. The reviewed materials make those distinctions visible in the product contract. They are local first-party evidence that the rules were intended and implemented; only a live role matrix and audit review could show that every deployed route enforces them consistently.", - "Flexible tables invite parallel work. One operator adjusts a controlled list while another edits a record against the old list; a third person imports a workbook exported earlier that morning. Silently accepting all three creates spreadsheet amnesia: the final table exists, but nobody can explain which assumptions survived. Requisia uses separate data and schema revisions so a mutation can declare the state it was based on. If that state is stale, the system can stop and ask for a fresh view rather than inventing a merge behind the operator's back.", - "A rejection is useful only when it remains legible. The interface should say that the underlying register changed, preserve the person's attempted work where safe, and offer a path to compare or retry. It should not expose private identifiers, internal storage details, or another organization's values while explaining the conflict. The current design supports this fail-closed direction, but the journal cannot certify the full experience. Concurrent edits, controlled-list changes, interrupted imports, and recovery after a rejected write still need repeatable environment-level evidence before anyone calls the behavior operationally complete.", - ], - }, - { - heading: "The workbook stays useful by losing authority", - paragraphs: [ - "None of this is an argument against Excel. It is an argument for giving the workbook a precise role. People can sort, review, annotate, and exchange a bounded representation while the register retains stable identities, schema meaning, and revision history. Export becomes a deliberate snapshot; import becomes a proposed change; and a generated file cannot quietly overwrite the accepted current version. The result is a gentler product because familiar tools remain available while the system, rather than human memory, carries the rules that make repeated exchange safe.", - "A complete organization-level lifecycle is the next credible proof: define fields, create records, export, edit, preview an import, resolve a conflict, accept a version, restore an earlier state, and confirm that another organization cannot observe any step. Someone other than the original implementer should run it and record outcomes without publishing business data. The private work currently supports the register boundary as a local design. Production readiness, deployment state, migration success, and customer use remain separate questions with no evidence supplied here.", - ], - }, - ], - relatedSlugs: [ - "requisia-preview-before-apply", - "requisia-current-workbook-pointer", - "insuja-typed-tenant-boundaries", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Preview Before Apply: Making Excel Imports Reversible", - slug: "requisia-preview-before-apply", - excerpt: - "A workbook upload can alter hundreds of procurement records at once, so Requisia separates bounded parsing, an intelligible preview, and a revision-aware transactional apply.", - status: "published", - date: "2026-07-16", - category: "Requisia", - project: "requisia", - tags: ["Import preview", "Merge semantics", "Replace confirmation"], - placement: "recent", - visual: { - variant: "paper-field", - alt: "Animated dither sheets separating into parse, preview, and apply stages", - }, - body: [ - { - heading: "An upload is a proposal, not a command", - paragraphs: [ - "A normal form usually changes one small object that a person can see. A workbook may carry hundreds of rows, removed values, reordered columns, and references created before the latest register edit. Treating that file as a large form submit hides the scale of the decision. Requisia instead frames an upload as a proposal. The system first establishes whether the file is bounded and intelligible, then describes the proposed changes, and only later accepts an explicit decision to apply them. The pause is part of the product, not friction around it.", - "Four stages bound what can be described from the approved local evidence: workbook parsing, preview generation, merge-or-replace intent, and apply. Stable record identity also matters more than visible row order. Those observations establish an implementation direction without establishing compatibility with an arbitrary production workbook. No customer file, live provider configuration, or deployed database supports this entry; readers should understand that missing environment evidence as a deliberate limit rather than assume the preview has already survived every operating condition.", - ], - }, - { - heading: "Bound the file before doing durable work", - paragraphs: [ - "The safest import is one that can refuse unreasonable input before it consumes unbounded time or creates partial state. Byte and row limits give the parser a known envelope. Column recognition, required values, controlled choices, and stable identities can then be evaluated without writing to the register. A malformed file should produce a useful, bounded explanation rather than a half-imported table. This protects both the operator's intent and the service from a document whose size or shape is different from what the product promised to handle.", - "Validation must also respect the register's current schema. A workbook exported under yesterday's fields cannot redefine today's controlled list merely because its header looks familiar. The preview can identify unknown columns, invalid choices, duplicate identities, or missing requirements and show where the proposal diverges. It should never echo unrelated private values into logs or error telemetry. The reviewed implementation contract supports early limits and authoritative schema rules; broad format compatibility, hostile-file behavior, and provider resource limits remain tests to run in the intended environment.", - ], - }, - { - heading: "Merge and replace answer different questions", - paragraphs: [ - "Merge asks how the proposed workbook changes known records while retaining other register state. Stable identities allow an edited row to remain the same record even when its label or position moves. New rows can be named as additions, changed cells as updates, and missing rows as unchanged unless the chosen operation says otherwise. This makes the preview conversational: it can tell the operator what will happen in the vocabulary of the register rather than presenting a raw diff that only an implementer can interpret.", - "Replace asks a much stronger question: should this workbook become the complete register, including the consequences of omissions? That intent deserves a fresh preview and an exact confirmation tied to the relevant module and proposal. A generic modal saying 'Are you sure?' does not communicate the scope. The design described in Requisia keeps merge and replace distinct so convenience cannot silently escalate authority. The public article records that design; it does not claim every deployed interface, API client, or retry path has been observed enforcing it.", - ], - }, - { - heading: "A preview expires when its assumptions change", - paragraphs: [ - "Between preview and apply, another person may edit a record or adjust the schema. Applying the old proposal as though nothing changed would turn the preview into theatre. Requisia binds the operation to the data and schema revisions it examined. When either has moved, the safer response is to stop and regenerate the preview against current state. The operator can then see whether the proposed change still means the same thing, rather than relying on an obsolete picture that happened to remain open in a browser tab.", - "Transactional apply provides the other half of reversibility. The accepted mutation should complete as one coherent register decision or leave the prior authoritative state intact; an interruption must not produce an unexplained mixture of old and new rows. That principle is visible in the reviewed roadmap and focused contracts. Production confidence would require deliberately interrupted applies, concurrent edits, retry exercises, database failure simulation, and a verified recovery path. Those exercises are not replaced by a passing parser test or a polished preview screen.", - ], - }, - { - heading: "Human review is part of the data model", - paragraphs: [ - "A strong preview shows meaning, not just volume. Counts help, but an operator also needs to distinguish additions, updates, invalid values, and destructive omissions; locate the affected records; and understand which rules produced a warning. The screen should keep keyboard navigation, readable contrast, and a durable way to revisit the decision. When the proposed change is large, the product should make caution easier than reflex. That is how a bulk workflow can remain comprehensible without pretending automation eliminated human responsibility.", - "A useful proof set would cover a small valid merge, a deliberate replace, a stale preview, a malformed file, a large valid file, a controlled-list conflict, an interrupted apply, and a safe retry. It should verify both register results and the operator-facing explanation while keeping real business data out of public evidence. Requisia's local design makes import reversible in structure and intent; production scale, live database behavior, recovery, and the correctness of any organization's uploaded workbook are still unverified.", - ], - }, - ], - relatedSlugs: [ - "requisia-organization-scoped-registers", - "requisia-current-workbook-pointer", - "requisia-composite-readiness", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Current Is a Pointer, Not a Convenient Regeneration", - slug: "requisia-current-workbook-pointer", - excerpt: - "Requisia gives the accepted Current workbook an explicit version pointer, so a newly generated file cannot silently impersonate the artifact people have chosen to rely on.", - status: "published", - date: "2026-07-15", - category: "Requisia", - project: "requisia", - tags: ["Current pointer", "Workbook versions", "Checksum history"], - placement: "stories", - visual: { - variant: "archive-lines", - alt: "Animated dither archive with one illuminated pointer selecting an accepted workbook version", - }, - body: [ - { - heading: "The word current needs a contract", - paragraphs: [ - "A download button labeled Current looks simple, yet it can hide two incompatible meanings. It might return the last workbook a person accepted, or it might regenerate a fresh file from whatever the database contains now. Those files can differ at exactly the moment someone needs certainty. Requisia defines Current as an authoritative pointer to a private, versioned workbook. Generation remains useful, but it creates a candidate or a new version; it does not rewrite the meaning of Current merely because producing another spreadsheet is technically easy.", - "Template state, generated workbooks, accepted versions, version metadata, and the Current pointer appear separately in the approved product record. Checksums identify the bytes associated with a version instead of trusting a mutable filename. That private observation can support a public discussion of the boundary, not a reproducible implementation review. It leaves open whether a production pointer exists, every historical object is recoverable, or any deployed download has been checked against a live storage provider.", - ], - }, - { - heading: "Version history makes missing state honest", - paragraphs: [ - "A procurement workbook is often both a working surface and a handoff artifact. If every UI edit simply regenerates the same path, a later reviewer cannot tell whether a difference came from an accepted import, an application edit, a template update, or a background process. Versioning creates room for that explanation. Each accepted artifact can retain its own metadata and checksum, while a deliberate pointer update says which version the organization currently recognizes as authoritative.", - "History is valuable only if it cannot be revised casually. Creating a new version should not alter the bytes or identity of an earlier one, and selecting Current should be a separate decision from generating a file. That lets an operator inspect a candidate, reject it, or move the pointer back when policy permits. The local contract makes these decisions distinct. It is not yet public proof of retention duration, object durability, rollback permissions, or the consistency of pointer changes under concurrent production use.", - "When the Current pointer is absent, the tempting fallback is to generate a workbook and return it so the button still appears to work. That response invents authority. The resulting bytes may be accurate as a projection of current records, but nobody selected them as the accepted artifact. Requisia treats a missing pointer as an explicit state the interface must explain. The user can then create or select a version through the intended workflow instead of receiving a convenient file with a misleading name.", - "The same principle applies when the pointer targets unavailable bytes or a checksum does not match. A bounded error should preserve the distinction between metadata and object availability, avoid exposing provider paths, and give an operator a recovery starting point. It should not redirect silently to a different version. The design material names checksum verification and private version handling, but actual failure behavior remains an environment question. Missing objects, corrupted bytes, provider outages, and permission changes require controlled tests before the system can make an operational reliability claim.", - ], - }, - { - heading: "Download authority is evaluated at request time", - paragraphs: [ - "Knowing the Current version does not grant access to it. A download still has to resolve the signed-in actor, organization, relevant module, permitted assignment, chosen version, and private object metadata. Browser-visible identifiers are references that help ask for a resource; they are not capabilities that bypass the current authorization decision. This matters when someone bookmarks a link, changes roles, or loses an assignment after the link was first shown.", - "A safe delivery path also keeps storage details on the server and streams only after the full decision succeeds. Email can point a recipient toward a signed-in destination without embedding the private file itself. These are high-level properties of the reviewed private implementation, not a disclosure of its topology. This note cannot show that session expiry, assignment revocation, parallel downloads, or partial streams behave correctly in production. Those claims need direct evidence from the intended runtime and real authorization configuration.", - ], - }, - { - heading: "A useful lifecycle closes the loop", - paragraphs: [ - "The strongest workbook story begins before download and ends after recovery. An organization defines its register, generates a candidate, reviews it, accepts a version, downloads exactly those bytes, makes a later change, accepts another version, and can still inspect the earlier artifact. Pointer history should explain which decision moved Current and when, without placing customer content or credentials in public logs. That sequence turns a collection of files into an accountable operating workflow.", - "Verification should deliberately test failed regeneration, concurrent pointer changes, checksum mismatch, missing objects, authorized rollback, retention, backup restoration, and access from the wrong organization. A public-safe record can report which boundary passed without publishing the workbook. The reviewed local design gives Current a durable meaning and avoids silent regeneration. Production storage, recovery, availability, and the state of any customer's accepted artifact stay outside that design-level finding.", - ], - }, - ], - relatedSlugs: [ - "requisia-organization-scoped-registers", - "requisia-preview-before-apply", - "requisia-private-object-delivery", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Portal Visibility Is Not Document Authority", - slug: "requisia-portal-and-document-assignments", - excerpt: - "Requisia separates the assignment that makes business work visible in a portal from the narrower, current authorization required to deliver a private document.", - status: "published", - date: "2026-07-14", - category: "Requisia", - project: "requisia", - tags: ["Portal assignments", "Document grants", "Recipient isolation"], - placement: "research", - visual: { - variant: "contract-bridge", - alt: "Animated dither bridge showing separate portal visibility and private document authorization lanes", - }, - body: [ - { - heading: "Seeing the work is not receiving the file", - paragraphs: [ - "A client or vendor portal needs to reveal enough context for a person to understand what requires attention. That visibility may include an RFQ, order, invoice, report, or another register record. It does not follow that every attachment connected to the visible record should be downloadable. Requisia models these as two assignments: one makes the relevant business object available in the portal, while another represents the active authorization for a specific private document. The separation prevents a broad workspace view from becoming an accidental file-sharing capability.", - "Portal assignments and document assignments appear as different product objects in Requisia's approved private notes, with separate revocation and delivery concerns. Preserving that reasoning publicly does not require exposing recipients, object locations, or operational identifiers. The evidence boundary stops at the reviewed product distinction: it cannot show that a production portal is configured, a real recipient has been invited, or every deployed download route currently performs the intended checks.", - ], - }, - { - heading: "Assignments describe purpose as well as identity", - paragraphs: [ - "A portal assignment answers why an external party can see a piece of work: perhaps a vendor is responding to a package, or a client is reviewing a report. That purpose shapes the fields and actions appropriate to the view. A document assignment answers a narrower question: may this signed-in recipient receive these private bytes now? Keeping the questions separate makes it possible to show a record after an attachment has been revoked, or share one attachment without exposing every file related to the same business entity.", - "This also improves interface clarity. A visible row can show that a document exists without presenting an active download action when the grant is absent, expired, or revoked. The screen does not have to pretend that all missing authority is a missing record. Conversely, a direct request for a private object cannot rely on the fact that the surrounding page once rendered. These behaviors are design expectations from local work; a full browser and direct-request matrix is still necessary to show they hold across real sessions and deployment boundaries.", - ], - }, - { - heading: "The session defines the recipient", - paragraphs: [ - "A client-supplied recipient field is not proof of who is making a request. Requisia derives the actor and organization from the signed-in session, then evaluates the active assignment for that context. The requested record or document identifier merely names what the person wants. This ordering resists a common failure mode in multi-party systems: changing a visible identifier until another organization's resource appears, even though the surrounding route and interface look normal.", - "Notifications follow the same boundary. A message can announce that new work is available and lead to a login destination, while private delivery remains behind the current session and assignment decision. Sending a durable object URL in email would freeze authority at message time and make later revocation unreliable. The reviewed material establishes that Requisia intends authenticated delivery rather than clever links. It does not prove deliverability, session behavior, or revocation timing with production providers, all of which remain external evidence gates.", - ], - }, - { - heading: "Revocation must survive old links", - paragraphs: [ - "People bookmark pages, forward messages, and leave tabs open. A meaningful revocation therefore cannot depend on hiding a button or removing a portal card. The server must re-evaluate the document assignment when the bytes are requested. If the grant no longer applies, the old reference stays a reference and yields no file. The product may still explain that access changed, but that explanation must avoid confirming private metadata to someone who is no longer an authorized recipient.", - "Assignment changes can race with active sessions or a stream already in progress, so the operational policy needs precision about when revocation takes effect. Different choices may be reasonable, but they should be documented, tested, and visible to operators. The local design gives revocation first-class status; this article cannot validate every timing edge. Direct URL replay, session expiry, recipient reassignment, parallel requests, and an interrupted stream require controlled environment tests rather than inference from a static permission check.", - ], - }, - { - heading: "Prove both halves of the boundary", - paragraphs: [ - "A representative journey should assign portal work to one external party, expose only the permitted fields, attach a private document through its own grant, deliver it after authentication, revoke that grant, and confirm that the surrounding business record remains visible if policy allows. A second organization and a different recipient should fail at both the interface and direct-request layers. Audit evidence should record decisions without copying private document content into an easier-to-leak channel.", - "Real client and vendor sessions, session expiry, assignment updates, recipient changes, old links, and provider failure all belong in that journey. Local tests or service-boundary review establish only a part of it. What the available design shows is independent modeling of portal visibility and document delivery, a useful foundation for least authority. Production isolation, customer access, notification delivery, and live revocation still need direct environment evidence.", - ], - }, - ], - relatedSlugs: [ - "requisia-rfq-package-contract", - "requisia-private-object-delivery", - "insuja-seller-controlled-releases", - ], - verifiedAt: "2026-07-17", - }, - { - title: "RFQ Packages Without a Shadow Source of Truth", - slug: "requisia-rfq-package-contract", - excerpt: - "Requisia composes an RFQ package from the existing register record, a targeted portal assignment, and separately authorized attachments instead of creating a second drifting database.", - status: "published", - date: "2026-07-13", - category: "Requisia", - project: "requisia", - tags: ["RFQ composition", "Field visibility", "Attachment separation"], - placement: "build-business", - visual: { - variant: "handoff-map", - alt: "Animated dither map assembling an RFQ record, portal view, and separately gated attachments", - }, - body: [ - { - heading: "A package should not become a second procurement system", - paragraphs: [ - "An RFQ package looks like a distinct product object because it has a recipient, a deadline, visible fields, and attachments. The easy implementation is to copy all of that into a special package store. The copy works at first, then begins to drift: a status changes in the register but not the package, a supplier name is corrected in one place, or a withdrawn attachment remains reachable from the other. Requisia avoids that shadow source of truth by composing the package around the existing vendor-RFQ register record.", - "Stable record identity, portal-visible fields, a targeted assignment, and separately granted private documents form the package in the approved local contract. Explaining that composition keeps the authoritative data boundary intelligible without reproducing private source. The contract is evidence of implementation direction only. It cannot demonstrate that a production RFQ has been issued, a vendor has received one, or live portal and storage configuration enforce every intended boundary.", - ], - }, - { - heading: "Composition defines the disclosure", - paragraphs: [ - "When the RFQ remains a register record, ordinary register rules continue to apply. Its stable identity survives a label edit, controlled fields keep their defined meanings, and a revision can expose when someone is acting on an older view. The portal does not need to invent a parallel status vocabulary. It can present a purpose-built view of the same business object, limited to the fields appropriate for the assigned vendor and the stage of the workflow.", - "This is more than data normalization. One source of truth creates a clearer conversation between internal operators and external participants: a correction is a register decision, portal visibility is an assignment decision, and file access is a document decision. Each can change without pretending the others changed automatically. The reviewed design supports this composition, but deployed consistency would need observation of edits, reassignment, concurrent updates, and stale portal sessions. A coherent model on paper cannot guarantee those runtime paths remain coherent.", - "A vendor does not need every internal field attached to an RFQ record. Internal notes, operational classifications, or other non-portal values should remain server-side even if the same record powers the external view. Requisia's field visibility boundary lets the package expose a purposeful subset rather than serializing the whole record and hiding parts with presentation code. That reduces the chance that an unstyled response, direct request, or later interface refactor reveals information the visible screen was never meant to carry.", - "Field visibility should also be evaluated against the current assignment and register schema. A field that was appropriate when a package was prepared may no longer be appropriate after policy changes, and an old browser response should not grant future access. The private design gives visibility an explicit role, yet this journal cannot certify every serialization path. Negative tests with hidden fields, direct identifiers, schema changes, cached views, and a different organization's session remain necessary before making a public isolation or security claim.", - ], - }, - { - heading: "Attachments keep their own gate", - paragraphs: [ - "An attachment may belong to the RFQ context without inheriting the RFQ's entire visibility policy. Some files could be intended for every assigned vendor, while another may be limited, replaced, or revoked independently. Requisia keeps those files as ordinary private documents with document-specific authorization. The package can name that an attachment is available, but the server still evaluates the signed-in recipient and active grant when bytes are requested. A visible package is therefore not a reusable download token.", - "This separation makes revocation and history easier to explain. Removing a document grant does not require deleting the RFQ record or pretending the package never existed; changing the portal assignment does not rewrite the file itself. Notification links can lead back to authentication rather than carrying storage authority. These are intended behaviors observed in local first-party work. Provider access, partial delivery, cache behavior, and revocation timing have not been established publicly and need controlled tests in the target environment.", - ], - }, - { - heading: "Exercise the package as a lifecycle", - paragraphs: [ - "A credible RFQ test begins with an internal record, selects portal fields, assigns one vendor, attaches two independently governed documents, and confirms that another vendor sees nothing. It then changes a visible value, hides a field, revokes one attachment, reassigns the package, and checks that history remains understandable. The exercise should include direct requests rather than trusting the buttons a portal happens to render, because the server boundary must survive clients that do not follow the interface's intended path.", - "Public evidence can report scenarios and bounded outcomes without revealing supplier names, commercial terms, documents, object locations, or session details. The architectural point already supported locally is that Requisia composes RFQ packages from existing authoritative objects instead of duplicating their truth. Production operation, vendor participation, live notification delivery, and complete protection against disclosure mistakes remain explicit verification responsibilities rather than benefits inferred from that model.", - ], - }, - ], - relatedSlugs: [ - "requisia-portal-and-document-assignments", - "requisia-session-derived-authority", - "insuja-formal-requests-and-qa", - ], - verifiedAt: "2026-07-17", - }, - { - title: "One Login Flow, Several Kinds of Authority", - slug: "requisia-session-derived-authority", - excerpt: - "Internal operators, administrators, clients, and vendors can enter through one Requisia login surface while each service decision still enforces role, organization, and action scope.", - status: "published", - date: "2026-07-12", - category: "Requisia", - project: "requisia", - tags: ["Session authority", "Role separation", "Organization scope"], - placement: "recent", - visual: { - variant: "split-horizon", - alt: "Animated dither horizon splitting one sign-in path into distinct role and organization decisions", - }, - body: [ - { - heading: "A shared doorway is not a shared room", - paragraphs: [ - "A single login surface can make an enterprise product feel coherent. Internal operators, administrators, clients, and vendors do not need four unrelated authentication brands simply because their work differs. The danger appears when that shared doorway is allowed to imply shared authority. Requisia keeps the entry experience common while treating every protected action as a new question about the signed-in actor, organization, role, resource, and current policy. Authentication begins the decision; it does not finish it.", - "Signed sessions feed separate rules for register edits, workbook operations, portal assignments, private documents, export, deletion, and other sensitive actions in the approved local authorization model. The public summary can name those distinctions without disclosing session formats, provider setup, internal routes, or organization details. That is enough to discuss deliberate separation of authority, but not enough to prove production identity-provider behavior, invitation handling, session expiry, or complete enforcement across deployed services.", - ], - }, - { - heading: "Identity and authority answer different questions", - paragraphs: [ - "Authentication establishes that a request presents a valid session for an actor. Authorization decides what that actor may do now. The second answer can change while the first remains true: a vendor's package can be withdrawn, a client's document grant can expire, an operator's role can be reduced, or an administrator can leave one organization while retaining access to another. Requisia therefore avoids treating a successful login as a durable ticket to every object that appeared during the session.", - "The distinction also prevents client input from repairing missing authority. Supplying an organization identifier, role name, or recipient value in a request cannot make a revoked session valid for that context. The server reconstructs the relevant scope from trusted state and checks the requested action independently. This is the expected behavior expressed by the local product contract. Public confidence would still require direct-request tests, changed roles during active sessions, cross-organization identifiers, and provider-backed identity evidence rather than interface observation alone.", - ], - }, - { - heading: "Roles are useful only beside resource rules", - paragraphs: [ - "A broad label such as administrator or vendor cannot capture every procurement decision. An administrator may manage fields but lack permission to perform a destructive purge; a vendor may see one assigned RFQ but not another; a client may view a report without receiving its underlying private workbook. Requisia combines the actor's role with organization and resource scope so a convenient label does not grow into universal authority. The product can then explain a denied action in business terms without revealing unrelated objects.", - "This approach encourages service-specific checks rather than one enormous gate at page entry. Loading a portal dashboard, editing a register record, selecting a Current workbook, and streaming a document each protect different consequences. A screen that was authorized five minutes ago cannot substitute for the check around today's mutation. The reviewed private design follows this layered direction. It remains possible for an unreviewed path or configuration mistake to violate it, which is why production claims require a complete role-and-action inventory plus negative runtime evidence.", - ], - }, - { - heading: "Revocation has to reach an active session", - paragraphs: [ - "Role and assignment changes matter most after a person has already signed in. If the application only checks authority when the session is created, revocation waits until a logout or distant expiry and becomes operationally weak. Requisia's decision model is designed to evaluate current role and scope at the protected boundary. A session can continue identifying the actor while a document request, register edit, or portal view is denied because the underlying grant changed.", - "The interface should handle that transition without treating it as a mysterious crash. It can explain that access changed, clear stale protected data, and return the person to an appropriate destination, while logs record a bounded reason rather than secrets or customer content. These are product expectations, not witnessed production outcomes. Revocation latency, multiple devices, clock behavior, recovery flows, and provider session semantics must be tested in the intended environment before anyone promises immediate or universal enforcement.", - ], - }, - { - heading: "The proof is a role matrix in motion", - paragraphs: [ - "A static table of roles is a starting point, but the persuasive test is a sequence. Invite each actor type, sign in, select an organization where appropriate, perform allowed work, attempt adjacent denied actions, change the role or assignment, and retry from the existing session and a direct request. Repeat the journey around records, workbooks, portal objects, private documents, export, and deletion. The evidence should make gaps visible without copying real identities or business data into public artifacts.", - "Invitation, recovery, expiry, revocation, organization switching, and an actor who belongs to more than one context must all appear in the lifecycle. Independent review of deployed identity and application settings belongs beside those journeys. The private local implementation supports separation between a common login experience and the product's different authorities. Live authentication, production authorization, customer access, recovery readiness, and freedom from security defects remain open evidence gates.", - ], - }, - ], - relatedSlugs: [ - "requisia-portal-and-document-assignments", - "requisia-private-object-delivery", - "insuja-identity-assurance-separation", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Private Documents Need Authenticated Delivery", - slug: "requisia-private-object-delivery", - excerpt: - "Requisia keeps private workbooks and documents behind a current server-side authorization decision instead of asking long, difficult-to-guess URLs to behave like access control.", - status: "published", - date: "2026-07-11", - category: "Requisia", - project: "requisia", - tags: ["Authenticated streaming", "Private objects", "Checksum delivery"], - placement: "stories", - visual: { - variant: "key-vault", - alt: "Animated dither vault opening only after session, assignment, version, and object checks align", - }, - body: [ - { - heading: "A URL should name a document, not authorize it", - paragraphs: [ - "Private procurement files often acquire links because links are convenient. The trouble begins when possession of the link is the only thing separating a workbook from the public internet. Links are copied into messages, browser history, support tickets, and analytics; they outlive the assignment that justified them. Requisia treats a browser-visible document or version identifier as a reference. It helps the signed-in person ask for an object, while the server decides whether the current actor and organization may receive the bytes now.", - "Document metadata, version identity, checksums, assignment state, and authenticated delivery remain separate concerns in the approved local design. This account can examine that separation while omitting object locations, provider configuration, routes, credentials, and customer material. It shows why the intended boundary does not rely on obscurity alone; it cannot show that a live storage bucket is private, every production URL is protected, or an external reviewer has assessed the deployed delivery path.", - ], - }, - { - heading: "Integrity and communication return to the same authority", - paragraphs: [ - "A product record can say which document exists, which version is selected, and which checksum identifies the expected bytes. The object provider stores those bytes, but it should not become the source of business authorization. Requisia resolves the signed-in context, organization, relevant assignment, selected version, and canonical metadata before opening a private stream. That ordering prevents a client from choosing a storage prefix or substituting an unrelated object merely because it discovered a plausible identifier.", - "Checksums add a useful integrity question: are the bytes being delivered the bytes recorded for this version? A mismatch should stop rather than silently return a file that happens to occupy the expected location. Yet a checksum cannot prove who may download the file or whether the content was originally correct; it serves one boundary. The local implementation expresses both metadata and integrity checks. Provider durability, live key policy, upload provenance, and end-to-end content correctness remain outside what this journal can verify.", - "Notification is useful when a client or vendor needs to know that new work is available. It should not freeze the authorization decision into the message. Requisia can send a destination that returns the recipient to the application, where login and the current assignment determine access. If the document is revoked after the email is sent, the old message no longer opens the bytes. This makes revocation a property of the product state instead of a race to retract every copied link.", - "The message also should not reveal private object names or embed credentials that support systems might later capture. Its job is to describe the action in clear language and lead back to authenticated context. The reviewed design maintains this separation between communication and delivery. This article does not claim that production messages are delivered, that unsubscribe or suppression state has been exercised for every recipient, or that every mail client handles links safely. Those are distinct notification and provider verification tasks.", - ], - }, - { - heading: "Failure needs a bounded shape", - paragraphs: [ - "Private delivery can fail because the assignment changed, the session expired, the version is missing, the object provider is unavailable, the checksum differs, or a stream ends early. Those conditions should not collapse into a fallback that serves another version or a public link. Requisia's design favors a bounded failure that preserves the authoritative record and gives an operator a useful category without exposing object paths, secrets, or another organization's document metadata.", - "Partial streams and retries deserve special care. A retry must repeat the authorization and integrity decisions rather than assuming the first attempt granted permanent access. Operational logs can distinguish requested, authorized, opened, completed, and failed delivery without recording the document itself. These are high-level expectations supported by local contract work. Actual behavior under provider outages, parallel requests, network interruption, and changed permission has not been publicly observed and cannot be inferred from the happy path.", - ], - }, - { - heading: "Test the reference after its authority disappears", - paragraphs: [ - "The most revealing exercise starts with a valid private download and keeps the reference while everything around it changes. Revoke the assignment, change the recipient, expire the session, select another Current version, remove the object, introduce a safe checksum mismatch, and retry directly. Repeat from a different organization and from an old notification. The expected result is not always the same error message, but no scenario should convert a stale reference into access or leak enough metadata to map private holdings.", - "A complete record should cover large files, parallel downloads, interrupted streams, provider errors, backup restoration, and operator response. Synthetic documents and redacted environmental values can keep that evidence safe for a public project. Current private work supports authenticated delivery around private objects and recorded integrity metadata. Production confidentiality, availability, recovery, and freedom from implementation flaws require the intended deployment and are not established by the local record.", - ], - }, - ], - relatedSlugs: [ - "requisia-current-workbook-pointer", - "requisia-portal-and-document-assignments", - "requisia-composite-readiness", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Readiness Is a Composite Signal, Not a Green Build", - slug: "requisia-composite-readiness", - excerpt: - "Requisia treats frontend compilation as one narrow result inside a larger readiness picture spanning sessions, data, private files, notifications, recovery, and representative journeys.", - status: "published", - date: "2026-07-10", - category: "Requisia", - project: "requisia", - tags: ["Composite readiness", "Recovery evidence", "Journey verification"], - placement: "research", - visual: { - variant: "release-bars", - alt: "Animated dither readiness bars that align only when product, provider, recovery, and journey evidence agree", - }, - body: [ - { - heading: "Green describes the check that ran", - paragraphs: [ - "A successful frontend build is valuable evidence: the source compiled under a known toolchain and produced an artifact. It says nothing by itself about whether sessions work, register data is reachable, private objects are protected, notifications can be sent, or a backup can be restored. Requisia treats readiness as a composite signal because the product crosses all of those boundaries. The release story should preserve each result instead of letting the brightest green check lend confidence to systems it never touched.", - "Source checks, target-environment readiness, provider configuration, representative journeys, backup, restore, rollback, and operator handoff are distinct gates in Requisia's approved readiness record. Their separation is the local observation worth carrying into this entry. Deployment values remain private, and none of the gates is presented as a production pass. A readiness command, checklist, or roadmap cannot substitute for current provider evidence, so the discussion must not be read as a live availability statement.", - ], - }, - { - heading: "Dependencies fail in different ways", - paragraphs: [ - "The application depends on several kinds of external state. Identity may accept a session while the product data store is unavailable; records may load while a private object cannot be streamed; the product can save a publication event while notification delivery is misconfigured. A useful readiness view checks the required boundary for the selected product mode and returns a non-success result when an essential dependency is absent or invalid. It should not mutate production merely to prove reachability.", - "Optional commercial or communication features also need honest treatment. A mode that does not require a provider should not fail because that provider is absent, while a mode that promises the feature must not mark itself ready using placeholder configuration. The output should name the category of failure without printing secrets or provider identifiers. Requisia's local operating design follows this redacted, fail-closed shape. Whether each external account and target environment currently satisfies it remains independent, drift-prone evidence.", - ], - }, - { - heading: "Readiness is not a restore drill", - paragraphs: [ - "A health check can confirm that a database responds and that expected migration state appears present. It cannot show that a backup contains the required data, that restoration completes in time, or that the restored application behaves correctly. Requisia keeps backup and restore evidence separate from deployment status for this reason. Recovery is a product capability exercised under controlled failure, not a sentence appended to a successful release command.", - "The same caution applies to private objects and register exports. Being able to generate an export is not proof that all private files can be restored, and a migration process returning success is not proof that rollback thresholds are understood. The local material names these boundaries and asks for explicit records. This journal has not run a production restore, inspected customer backups, or verified provider retention. It therefore cannot turn recovery plans into claims of recoverability.", - ], - }, - { - heading: "A representative journey connects the checks", - paragraphs: [ - "Even healthy dependencies can compose into a broken product. A representative Requisia journey should authenticate the appropriate actors, create and edit organization-scoped register state, exchange a workbook through preview and apply, select a Current version, assign portal work, deliver a permitted private document, revoke access, export, and exercise the supported recovery boundary. The journey reveals mismatched assumptions between parts that isolated checks report as healthy.", - "Representative does not mean exhaustive or based on real customer content. Synthetic organization data can cover the authority and lifecycle decisions while keeping evidence safe for a public record. Negative steps matter alongside the successful path: a wrong organization, stale preview, revoked file, missing pointer, and failed dependency should remain bounded and intelligible. The reviewed roadmap calls for this kind of evidence, but the existence of the plan does not establish that the entire journey has passed in any live environment.", - ], - }, - { - heading: "Handoff completes the readiness picture", - paragraphs: [ - "A system is fragile when only its original implementer knows which warning can be ignored, where recovery begins, or which optional mode is active. A credible handoff names the artifact, environment, evidence dates, unresolved risks, rollback thresholds, recovery responsibilities, and owners for manual gates. Someone else should be able to repeat the readiness checks and explain the result without private oral context. That standard makes uncertainty visible rather than converting familiarity into an unreviewed production assumption.", - "Requisia needs an aligned set of current, redacted results rather than one larger green badge: release checks, target dependency readiness, a representative procurement journey, negative authorization cases, a backup-and-restore exercise, a rollback decision, and operator handoff. The private local work currently supports only the idea that readiness is composite evidence. Deployment, production readiness, customer operation, security closure, and successful disaster recovery remain unproven until their own records exist.", - ], - }, - ], - relatedSlugs: [ - "requisia-preview-before-apply", - "requisia-private-object-delivery", - "gy-qualification-before-release", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Context Budgets Are a Product Boundary", - slug: "hyoka-context-budgets", - excerpt: - "Context is a finite, user-visible selection of instructions, conversation, project evidence, and tool results, so its budget belongs in product behavior rather than hidden model arithmetic.", - status: "published", - date: "2026-07-01", - category: "Hyoka Hanesu", - project: "hyoka-hanesu", - tags: ["Context budgets", "Selection policy", "Visible limits"], - placement: "build-business", - visual: { - variant: "context-rings", - alt: "Animated dither rings allocating a finite context budget around a focused question", - }, - body: [ - { - heading: "Context is an editorial decision", - paragraphs: [ - "An assistant never reasons over an entire working world at once. It receives a selection: current instructions, recent conversation, excerpts from the chosen project, and results returned by approved tools. Calling that bundle ‘context’ can make it sound automatic, but every inclusion and omission changes the answer. Hyoka Hanesu treats the selection as an editorial product decision. The system should gather enough evidence to support the current question while resisting the tempting fiction that more material is always better or that an unseen limit has no effect on meaning.", - "Context assembly and budgeting appear as explicit concerns in the approved local product record. Private prompts, project excerpts, machine limits, and service settings are neither published nor needed to explain that principle. The observation cannot support universal answer quality, benchmark leadership, or predictable resource use in a deployed service. It supports a smaller proposition: a repository assistant is easier to understand when the product owns what it selects, what it leaves out, and how it communicates the difference.", - ], - }, - { - heading: "Budget the evidence and expose the omissions", - paragraphs: [ - "A single total hides competing responsibilities. Instructions define the operating boundary; conversation carries the person's current intent; repository excerpts provide evidence; tool results report new observations; and the assistant needs room to produce a useful response. If any one category can consume the full allowance, the others become accidental casualties. A practical budget therefore reserves space by role and prioritizes current, directly relevant evidence over repeated background. The exact numbers may vary by backend, but the product policy should remain explainable without exposing internal calculations.", - "This layered view also prevents large outputs from becoming authority merely because they are large. A verbose command result may contain less useful evidence than a short focused excerpt, and a long conversation may repeat assumptions that the current project contradicts. Selection should account for provenance, recency, and relevance, not just byte order. The reviewed design notes point in that direction, but this article does not assert a perfected ranking system. Representative tasks and deliberate adversarial cases would be needed to show whether the policy consistently preserves the evidence that matters.", - "When a budget fills, silent truncation is the most damaging response. It lets the interface imply continuity while removing the very definition, decision, or error that explains the next answer. A better product marks that some material was not carried forward, summarizes only when the source remains identifiable, and offers a way to refocus or retrieve the missing evidence. The person should not need to reverse-engineer a sudden change in tone to discover that an earlier constraint fell outside the current window.", - "Visibility does not require flooding the interface with token counters. Human language can describe whether the assistant used the whole selected project, a focused set of files, a shortened tool result, or a condensed conversation. The important promise is semantic: the product must not present an incomplete selection as complete knowledge. Local tests can verify deterministic trimming and interface notices for constructed inputs. They cannot prove that every real project, language, or model will interpret a summary faithfully, so that broader assurance remains outside this journal.", - ], - }, - { - heading: "Backend changes must not erase the contract", - paragraphs: [ - "Different model paths may accept different context sizes and may count the same material differently. If the interface simply inherits those differences, changing a backend can unpredictably remove conversation, admit larger tool results, or crowd out the response. Hyoka Hanesu instead needs a product-level contract that can be mapped onto each available capability. The contract can adapt its totals, but it should preserve ordering rules, protected instruction space, disclosure of omissions, and a minimum allowance for a coherent answer.", - "A stable contract does not imply equivalent intelligence. Two models can receive the same carefully selected evidence and still produce different interpretations, latency, or language. This article makes no claim of model parity and offers no provider performance comparison. It argues only that the selection boundary should remain under product control so backend variability does not become invisible behavior drift. Proving that mapping would require the supported backends to be exercised against the same context cases in the intended release environment, with differences recorded rather than averaged away.", - ], - }, - { - heading: "A budget earns trust through repeatable pressure tests", - paragraphs: [ - "The next credible test set should include a long conversation with one decisive early constraint, a large project with one relevant definition, an oversized tool result, repeated content, conflicting recent evidence, and a backend with a smaller allowance. Each case should record what was selected, what was dropped, what the person was told, and whether the answer still cites the governing evidence. Reduced-motion, keyboard, and narrow-screen behavior matter too, because a disclosure that disappears in a particular interface state is not a reliable product boundary.", - "Focused local cases can support the selection algorithm and its presentation, not universal model quality or production resource guarantees. Clean release builds, representative workloads, memory and latency observation, backend failure exercises, and independent review of omission behavior belong to stronger evidence. The product policy currently treats context budgets as visible. It offers no basis for saying every answer contains all relevant knowledge, summaries are lossless, or a private prototype is operationally ready for the public.", - ], - }, - ], - relatedSlugs: [ - "hyoka-opt-in-repository-access", - "hyoka-provider-boundaries", - "insuja-permission-safe-search-feed", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Local Models and Remote Providers Need an Honest Boundary", - slug: "hyoka-provider-boundaries", - excerpt: - "A shared assistant interface should say when work stays on the machine, when selected material may cross a service boundary, and which capabilities genuinely differ between those paths.", - status: "published", - date: "2026-06-30", - category: "Hyoka Hanesu", - project: "hyoka-hanesu", - tags: ["Backend choice", "Data boundaries", "Capability negotiation"], - placement: "recent", - visual: { - variant: "signal-window", - alt: "Animated dither gate separating a local model field from a remote processing field", - }, - body: [ - { - heading: "Backend choice changes the journey of the data", - paragraphs: [ - "A local model and a remote provider may both accept a prompt and stream an answer, but the similarity ends at the interface. Local processing keeps the main inference path on the person's machine and competes for local resources. Remote processing sends a deliberately assembled request beyond that machine and depends on a service boundary. Hyoka Hanesu should make that distinction visible before a project excerpt becomes part of a request. A backend selector is therefore a data-path decision, not merely a preference for one model name over another.", - "The approved local product direction separates these paths without disclosing prompts, credentials, service settings, machine details, or project contents. What a provider retains, how a production service is configured, and whether a local runtime is isolated from every other process remain outside that record. Those questions require provider documentation, verified deployment settings, and environment-specific observation. Here the claim is confined to product behavior: the interface must present the chosen path honestly and keep consent tied to it.", - ], - }, - { - heading: "Capabilities should be discovered, not imagined", - paragraphs: [ - "Backends can differ in available context, supported tools, streaming behavior, cancellation, structured output, and failure reporting. Pretending those differences do not exist produces fragile behavior: a control appears available, the request begins, and only then does the person learn that the selected path cannot honor it. A more predictable assistant establishes capabilities first and shapes the interface around what is actually available. Unsupported actions should be disabled or explained before work starts rather than translated into a vague downstream error.", - "Capability discovery also needs conservative defaults. An unknown response should not be interpreted as permission to use the richest feature set, and a backend change should invalidate assumptions learned from the previous one. The first-party notes indicate that backend differences are part of the product model, but this public account does not certify every capability mapping. A release claim would require repeated checks against each supported path, including version changes, partial responses, cancellation, missing features, and recovery after an interrupted stream.", - ], - }, - { - heading: "Disclosure belongs before transmission", - paragraphs: [ - "When remote processing is selected, the interface should describe the categories of material prepared for the request: current instructions, relevant conversation, chosen project excerpts, and approved tool results. It need not reveal sensitive content a second time, but it should make the scope intelligible and let the person cancel or narrow it. Local processing deserves equally careful language; ‘local’ should describe where inference is intended to occur, not become a sweeping promise that no component ever performs networking or writes temporary state.", - "The product should also exclude obvious credentials and unrelated private material before either path receives context. That is defense in depth, not permission to gather broadly and filter later. Explicit repository scope and context budgets remain the earlier boundaries. This journal records the intended ordering without claiming a comprehensive secret detector, legal compliance, or zero disclosure risk. Stronger assurance would require representative sensitive fixtures, network observation, retention review, and independent attempts to make disallowed material cross the chosen boundary.", - ], - }, - { - heading: "One interface must not promise identical behavior", - paragraphs: [ - "Consistency is valuable when it preserves understandable controls: send, stop, retry, inspect tool intent, and change the selected project. It becomes misleading when the same surface implies that local and remote backends have equal quality, latency, privacy properties, or tool support. Hyoka Hanesu can keep the conversation model familiar while naming meaningful differences near the decision that exposes them. A graceful fallback should ask for a new choice when behavior changes materially, not silently move work to another path to keep the screen busy.", - "Failure semantics are part of that honesty. If a local model is unavailable, the product should not contact a remote service automatically; if a remote request fails, it should not replay private context through a different service without renewed intent. Retrying the same path may still need safeguards against duplicated side effects from tools. These are design requirements distilled from local work, not evidence of complete implementation in a public release. Offline, degraded-service, cancellation, and backend-switch cases remain necessary verification work.", - ], - }, - { - heading: "Proof must follow each side of the boundary", - paragraphs: [ - "A credible verification matrix would run the same bounded tasks through every supported backend and observe data flow, context selection, visible capabilities, cancellation, errors, and backend changes. The local path should be exercised without external connectivity; the remote path should be inspected to confirm that only the disclosed request leaves the machine. Tests should also cover unavailable models, smaller context allowances, interrupted streams, stale capability information, and attempts to trigger an automatic fallback. The expected differences should be documented rather than treated as noise.", - "Even a passing matrix would not prove provider privacy, equivalent model behavior, a notarized distribution, or live service reliability. Those questions require the actual release and operating environment, plus current provider commitments where relevant. The private local record supports designing local and remote paths as distinct, visible boundaries under one interface. Production configuration, external service behavior, and distribution readiness remain separate, unverified evidence classes.", - ], - }, - ], - relatedSlugs: [ - "hyoka-opt-in-repository-access", - "hyoka-context-budgets", - "insuja-identity-assurance-separation", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Seller Releases as Explicit Controlled Disclosure", - slug: "insuja-seller-controlled-releases", - excerpt: - "Insuja treats seller disclosure as an explicit release event, preserving the line between private preparation and the exact deal material a chosen buyer may receive.", - status: "published", - date: "2026-07-06", - category: "Insuja", - project: "insuja", - tags: ["Seller disclosure", "Release boundaries", "Audience control"], - placement: "research", - visual: { - variant: "split-horizon", - alt: "Animated dither horizon separating seller-private material from a narrow illuminated release channel", - }, - body: [ - { - heading: "Sharing should be a deliberate state change", - paragraphs: [ - "A seller workspace can contain drafts, working notes, candidate files, and internal decisions long before any buyer should see them. If visibility is inferred from where an item sits or whether someone copied a link, private preparation can become disclosure by accident. Insuja instead frames a seller release as an explicit state change. Material remains seller-private until an authorized seller action identifies what is being released, to whom it is being released, and which shared workflow may present it.", - "Seller-controlled state and buyer-visible shared state remain distinct in the approved local model, and release is treated as a meaningful action rather than a display preference. That focused observation is enough to explain why disclosure needs its own state transition. The underlying implementation remains private, so the entry cannot verify a production tenant, report a real seller completing a release, or demonstrate that every deployed delivery surface enforces the boundary without exception.", - ], - }, - { - heading: "Name the subject, audience, and purpose", - paragraphs: [ - "A useful disclosure decision names a stable subject. Depending on the workflow, that might be a selected document version, a bounded set of answered fields, or a prepared response to a formal request. A vague instruction to share the deal is too broad because a deal continues to change. The seller should be able to review the exact material and audience represented by the action, while the system records enough context to distinguish the released snapshot from later private edits.", - "Consider a hypothetical financial summary that a seller prepares over several revisions. Releasing the reviewed revision to one buyer should not expose the next internal draft, and correcting that draft should not silently rewrite what the buyer previously received. The interface can present the new revision as another release decision. This makes the handoff understandable to both sides and prevents ordinary editing from acquiring the authority of publication merely because the content has a familiar title.", - "A buyer's participation in one opportunity does not make every seller release visible, and a release to one buyer does not establish a general catalogue. The decision should remain scoped to the intended tenant relationship, recipient group, resource, and action. Shared request or Q&A state may reveal that a response exists while the released payload follows its narrower permission. That distinction lets the workflow remain legible without turning a status update into a substitute for content authorization.", - "The same rule applies outside the main detail view. Search results, activity summaries, notifications, exports, and recent-item lists must derive their visible fields from the current release boundary. A notification can say that a response is available and lead the recipient back through a fresh permission decision; it need not copy sensitive text into an email. The local design points toward this least-disclosure approach, but live provider behavior and end-to-end production delivery remain unverified by this article.", - ], - }, - { - heading: "Correction and withdrawal do not erase history", - paragraphs: [ - "Sellers need a way to correct or withdraw material, yet the product should describe honestly what those actions mean. A new release can supersede an earlier one for future service-mediated access, and a withdrawal can stop later reads when policy allows. Neither action can guarantee that a recipient forgets information already viewed or that an independently saved copy disappears. Precise language preserves trust by promising control over the system's current surfaces instead of imaginary control over another person's memory.", - "An accountable history should therefore record that a release, replacement, or withdrawal occurred without placing the sensitive payload into a broadly readable log. The record can support questions about who acted, what bounded subject changed, which audience was intended, and when the decision took effect. Those are high-level expectations from first-party work, not evidence of a complete operational audit system. Retention, recovery, support access, and review procedures still require separate deployment evidence and policy approval.", - ], - }, - { - heading: "Prove the handoff from both sides", - paragraphs: [ - "A representative verification journey should begin with seller-private material and confirm that the buyer cannot discover it through direct navigation, search, counts, or notifications. The seller then releases a reviewed subject to one buyer, after which that buyer can find and read only the intended material while another buyer still sees nothing. The journey should continue through a correction, a withdrawal, a stale browser view, and an old link, checking the seller and buyer experiences at every transition.", - "The private record supports explicit seller disclosure separated from private preparation. Organization bootstrap, external identity, provider delivery, propagation timing, recovery, and independent adversarial review remain outside it. An explicit release makes the decision reviewable; operational assurance requires following that release through every downstream surface. The durable question after release, replacement, or withdrawal is who can see which bounded subject now.", - ], - }, - ], - relatedSlugs: [ - "insuja-revocable-permission-proofs", - "insuja-buyer-command-workspaces", - "insuja-formal-requests-and-qa", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Buyer Workspaces Without Seller Data Leakage", - slug: "insuja-buyer-command-workspaces", - excerpt: - "Insuja gives buyer teams a private command workspace for their own diligence while keeping seller material governed by explicit releases and current permission.", - status: "published", - date: "2026-07-05", - category: "Insuja", - project: "insuja", - tags: ["Buyer-private work", "Data separation", "Controlled references"], - placement: "build-business", - visual: { - variant: "workspace-beacon", - alt: "Animated dither workspaces with a buyer beacon illuminating only explicitly released seller material", - }, - body: [ - { - heading: "A buyer needs room to think privately", - paragraphs: [ - "A diligence team produces its own sensitive material: screening notes, internal questions, review assignments, tentative interpretations, and decisions about what to investigate next. That work should not appear in the seller's workspace merely because both parties participate in the same opportunity. Insuja treats the buyer command workspace as a separate ownership boundary. Shared deal activity can connect the parties, while buyer-private analysis remains visible only to the buyer tenant and the people currently authorized within it.", - "Seller, buyer, and shared workflow boundaries occupy separate parts of Insuja's approved local product model. The distinction supports one public observation: buyer work is not simply another view of seller state. It records design intent and focused implementation direction without proving production isolation, real participant onboarding, external identity behavior, or complete deployed authorization coverage. Explaining that ownership boundary requires no actual deal, tenant, or operational identifier.", - ], - }, - { - heading: "Shared references should not become copied authority", - paragraphs: [ - "A buyer workspace may need to point to material the seller released, but copying the seller payload into every buyer record creates a second disclosure system that can outlive withdrawal. A safer model keeps the buyer's annotation and workflow state separate from the governed seller resource. The reference helps the interface locate the subject, while a current permission decision determines whether the seller content can still be rendered. Losing access can leave the buyer's own note intact without preserving protected seller text inside it.", - "Imagine a reviewer writing, ‘Revisit the margin assumptions,’ beside a released summary. That buyer-authored instruction can remain useful if the seller later withdraws the summary, but the screen should no longer reproduce the unavailable figures. If the product permits a durable buyer snapshot, that must be an explicit, policy-visible capability rather than an accidental consequence of caching. The distinction makes data handling explainable and gives both parties a clearer account of what the system actually controls.", - ], - }, - { - heading: "Collaboration remains tenant-scoped", - paragraphs: [ - "Buyer teammates need assignments, status, comments, and search across their own diligence work. Each of those conveniences must begin with buyer-tenant scope and current membership. A person invited to a different opportunity should not inherit unrelated notes simply because their account already exists, and someone removed from the buyer team should not retain access through an old tab or remembered reference. Navigation and hidden controls support usability, but server-side resource decisions remain the authority for every direct request.", - "The same scope applies to derived surfaces. Activity counts should not reveal another buyer team's workload; search should not index seller-private titles that were never released; notification previews should avoid copying protected content; and exports should contain only the buyer-owned and currently permitted fields declared by their purpose. These are local first-party design expectations. Actual background processing, cache expiry, email behavior, and export delivery in an intended deployment remain evidence gates rather than conclusions that can be drawn from this journal.", - ], - }, - { - heading: "Derived conclusions need visible provenance", - paragraphs: [ - "Buyer analysis often combines observations from several released items with the team's own judgment. The interface should distinguish those layers so a reader can tell whether a statement is seller-provided, buyer-authored, or a hypothetical conclusion under review. Provenance also helps when a source release changes: the team can identify which notes need reconsideration without letting a changed seller document silently rewrite the buyer's history. Clear attribution is a product aid, not a claim that the system can determine whether a human conclusion is correct.", - "Deletion and retention deserve equally explicit language. Removing a buyer note can follow the buyer tenant's policy, while withdrawing seller access follows the seller's release decision; neither should cascade into the other's authoritative state by accident. Any retained audit facts should minimize payload content and remain protected. The reviewed private work establishes the conceptual separation, but public evidence would still need approved retention rules, recovery exercises, representative user review, and confirmation that provider-level copies follow the intended lifecycle.", - ], - }, - { - heading: "Test with two buyers and one changing release", - paragraphs: [ - "A useful verification journey gives two independent buyer tenants access to different releases from the same hypothetical seller. Each team creates private notes, assignments, searches, and notifications. The test then changes one seller release, removes one buyer member, withdraws another item, and attempts direct access with stale references. Success means each buyer retains only its own work, currently authorized seller material appears only where intended, and shared workflow status never smuggles the protected payload across a boundary.", - "The private evidence supports a buyer command workspace as its own tenant-scoped domain with seller disclosure under separate authority. Live organization bootstrap, deployed behavior, recovery, provider isolation, and independent security review are not part of that record. Separating ownership from reference makes leakage paths easier to reason about. A one-seller, two-buyer exercise with a changing release is the end-to-end evidence still needed from the environment that will operate the product.", - ], - }, - ], - relatedSlugs: [ - "insuja-seller-controlled-releases", - "insuja-formal-requests-and-qa", - "insuja-permission-safe-search-feed", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Tenant Boundaries as Types, Not Repeated Strings", - slug: "insuja-typed-tenant-boundaries", - excerpt: - "Insuja treats tenant scope as a value the application must establish before business work begins, replacing scattered organization strings with one explicit and reviewable boundary.", - status: "published", - date: "2026-07-09", - category: "Insuja", - project: "insuja", - tags: ["Tenant scope types", "Boundary resolution", "Cross-tenant denial"], - placement: "build-business", - visual: { - variant: "context-rings", - alt: "Animated dither rings holding separate tenant contexts without allowing their edges to overlap", - }, - body: [ - { - heading: "Scope should not be a loose convention", - paragraphs: [ - "A multi-tenant product can look well separated while every request still passes an organization name through several layers as ordinary text. That pattern asks each reader, helper, and background task to remember what the text means and where it came from. One missed comparison can turn a valid record reference into a cross-tenant read. Insuja's design instead treats tenant scope as a distinct value that must be established before deal data can be requested, changed, searched, or shared.", - "Trusted scope is distinct from user-supplied references in the approved local design, and tenant context is expected to accompany later decisions. That makes the boundary a product constraint rather than a label added for documentation. The observation can support a public account of intent and structure, but it cannot prove that a production deployment, an external identity provider, or every live data operation currently applies the constraint without exception.", - ], - }, - { - heading: "Resolve scope before granting capability", - paragraphs: [ - "A request may arrive with a session, a workspace selection, and a reference to a deal, yet those inputs do not deserve equal authority. The system should resolve the signed-in actor and their available tenant memberships from trusted state, select a valid context, and only then look up a tenant-owned resource. Repeating that resolution inside every feature invites drift. Establishing it once gives the rest of the operation a narrower vocabulary: it can receive scoped capabilities instead of rebuilding trust from strings.", - "This ordering also makes missing context safe. If membership cannot be established, the operation stops before it asks whether a referenced object exists. There is no universal fallback tenant and no helpful guess based on the last page someone visited. The interface can ask the person to choose an available workspace again, but it should not convert ambiguity into access. A typed boundary is valuable because an unresolved state remains visibly incomplete rather than becoming an empty string that later code may accept.", - "Tenant membership is necessary, but it is not the same as authority to perform every action inside that tenant. A useful scoped value can carry or lead to the permitted operation: view a shared release, answer a formal request, manage seller disclosure, or work inside a buyer-private space. Features then ask for the capability they actually require. That is easier to review than a generic tenant identifier passed into code that silently decides whether the caller is an administrator, participant, or observer.", - "The distinction becomes especially important when a person belongs to more than one tenant or changes roles during an active session. A resource reference from one workspace must not become meaningful after the interface switches to another, and a previously opened screen must not preserve authority after membership changes. Insuja's local design points toward fresh server-side decisions at meaningful boundaries. The journal cannot establish whether all caches, long-lived views, or asynchronous work have been exercised under those transitions in a deployed environment.", - ], - }, - { - heading: "Failure should remain inside the boundary", - paragraphs: [ - "A denial can leak data even when it returns no record. Different messages for nonexistent, inaccessible, and differently owned objects allow repeated guesses to reveal which references are real. Tenant-safe behavior therefore keeps outward responses deliberately modest while retaining enough private diagnostic context for authorized operators. Search results, counts, activity summaries, and notification previews deserve the same treatment; a perfectly protected detail page does not help if a sidebar already disclosed another tenant's title.", - "Background work needs equal discipline. A queued task should carry a bounded purpose and re-establish the authority needed for its action rather than relying on ambient global state. Retries should not drift into a different tenant because a default changed, and logs should describe outcomes without copying sensitive deal content. These are architectural expectations observed in first-party planning and focused local behavior, not claims that a live queue, monitoring system, or operational response has passed production review.", - ], - }, - { - heading: "Proof requires adversarial journeys", - paragraphs: [ - "The strongest test is not a successful read in the expected workspace. It is a matrix of negative journeys: reuse a reference after switching tenants, remove membership while a page is open, retry a stale action, search for a known title from the wrong side, and inspect whether totals or timing expose anything. The same matrix should cover direct navigation, bulk operations, background completion, and notification rendering. Each refusal should be stable, comprehensible, and free of information about the protected resource.", - "Those adversarial journeys define the remaining evidence gap. The available private record supports tenant context as an explicit local boundary with later permissions composed inside it. Repeatable tests against the intended deployment, representative role changes, external-service evidence, and independent review are still required. A type-shaped scope makes unsafe states harder to express and easier to review; it is not a certificate of deployed isolation.", - ], - }, - ], - relatedSlugs: [ - "insuja-identity-assurance-separation", - "insuja-revocable-permission-proofs", - "insuja-permission-safe-search-feed", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Login Assurance Is Not Data Permission", - slug: "insuja-identity-assurance-separation", - excerpt: - "Insuja separates confidence in a signed-in actor from permission to see a particular deal object, so a strong login never becomes a universal data pass.", - status: "published", - date: "2026-07-08", - category: "Insuja", - project: "insuja", - tags: ["Identity assurance", "Resource authorization", "Session transitions"], - placement: "recent", - visual: { - variant: "key-vault", - alt: "Animated dither key approaching several vaults while only one resource-specific door opens", - }, - body: [ - { - heading: "Authentication answers one question", - paragraphs: [ - "A successful login can establish that the current session belongs to a known actor with an acceptable level of assurance. It cannot establish that the actor may read every opportunity, attachment, message, or workspace the application can address. Collapsing those questions feels efficient because both are called access, but it gives identity evidence a power it does not contain. Insuja's design keeps authentication as the start of a decision and evaluates data permission against the requested resource and action afterward.", - "Three decisions appear separately in the approved local product boundary: identity establishes the actor, tenant context establishes the relevant organization, and policy determines what the actor may do. Their separation is credible evidence of intended design and focused implementation behavior. It supplies no public proof for production identity settings, provider operation, account recovery, or complete authorization coverage across a deployed service.", - ], - }, - { - heading: "Assurance belongs to the session", - paragraphs: [ - "Identity assurance has its own lifecycle. A session can be fresh or old, a sign-in method can provide different confidence, and a sensitive action can reasonably require a recent confirmation. Those properties describe how much confidence the service has in the actor at this moment. They should shape session renewal and step-up prompts without being mistaken for ownership of a deal. A recently verified buyer still cannot open seller-private material that was never released to that buyer.", - "The reverse is also important. A person may have a legitimate resource permission while their session is no longer strong enough to exercise it safely. The correct response is to renew identity assurance and then reevaluate the resource decision, not to cache the earlier answer indefinitely. This composition produces understandable states: sign in, confirm again, choose a valid tenant, or request access. Each state corresponds to a missing condition instead of presenting one vague denial that encourages unsafe shortcuts.", - ], - }, - { - heading: "Permission belongs to the resource", - paragraphs: [ - "A deal object has relationships that a login token cannot know by itself: which tenant owns it, whether the actor participates, whether a seller released a specific item, whether a buyer-private note is involved, and which action is requested. Authorization should evaluate those facts using authoritative current state. Passing only an actor role such as buyer or seller is too coarse. Roles help describe possible responsibilities, but the resource relationship determines whether a concrete read or mutation is allowed.", - "This boundary prevents broad interfaces from becoming accidental policy. A navigation link, a hidden button, or a filtered list may improve usability, yet none can grant authority. Direct requests must receive the same server-side resource evaluation even when the interface never offered the action. The locally reviewed design follows that principle at its declared boundaries. Production confidence would still need route inventories, negative tests, role-change exercises, and evidence that alternate clients cannot bypass the same policy decision.", - ], - }, - { - heading: "Denial should be ordinary and legible", - paragraphs: [ - "When authentication and permission are separate, the product can explain failure without exposing protected facts. An expired session can invite reauthentication. A missing tenant membership can invite a workspace change. A resource denial can remain intentionally neutral about whether the referenced deal exists. The interface should preserve safe work where possible, avoid loops between sign-in and denial screens, and never ask the person to solve an authorization problem by repeatedly supplying private references.", - "Audit events need the same separation. Recording that an authenticated actor attempted a denied action can support review, but the record should minimize copied deal content and should not turn routine denials into noisy security theatre. Operational detail belongs in protected evidence with bounded retention and access. The public journal can describe those design expectations, while actual monitoring coverage, retention policy, and response practice remain deployment questions that cannot be inferred from local application behavior.", - ], - }, - { - heading: "Test the composition, not the labels", - paragraphs: [ - "A useful verification matrix changes one condition at a time. Keep the same actor and change the tenant; keep the tenant and change the deal relationship; revoke a release while retaining the session; age the session while retaining permission; then repeat through direct navigation, search, downloads, and background work. Success means each layer contributes only its intended authority. A strong identity should never expand the resource set, and a valid resource relationship should never excuse inadequate session assurance.", - "The matrix also defines the evidence limit. Insuja's private local work deliberately separates identity assurance from data permission and exposes that distinction in the design. Separating the questions makes reviews and failures more precise, but live identity-provider behavior, real organizations, recovery flows, and every delivery channel need environment-level verification. Deployed assurance begins with that matrix and independent adversarial testing, not with the architectural separation alone.", - ], - }, - ], - relatedSlugs: [ - "insuja-typed-tenant-boundaries", - "insuja-revocable-permission-proofs", - "insuja-seller-controlled-releases", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Revocable Permission Proofs for Sensitive Deal Data", - slug: "insuja-revocable-permission-proofs", - excerpt: - "Insuja models permission to sensitive deal data as bounded, purpose-specific proof that can expire or be revoked without pretending a past grant lasts forever.", - status: "published", - date: "2026-07-07", - category: "Insuja", - project: "insuja", - tags: ["Permission proofs", "Revocation semantics", "Purpose limitation"], - placement: "stories", - visual: { - variant: "signal-window", - alt: "Animated dither signal passing through a narrow permission window that can close immediately", - }, - body: [ - { - heading: "A grant should be a bounded fact", - paragraphs: [ - "Sensitive deal work often needs more precision than a permanent member list. A seller may allow one buyer to view one released item for a defined purpose while keeping drafts, internal notes, and later versions private. Representing that decision as a generic can-view flag loses the subject, object, action, and lifecycle that made the grant reasonable. Insuja's design treats permission as proof of a specific relationship, so later reads can ask what was granted instead of assuming participation means universal visibility.", - "Permission is evaluated beside tenant, resource, actor, and requested action in Insuja's approved local model. That relationship supplies the architectural basis for this discussion while leaving the implementation evidence private. It cannot establish a production authorization service, live revocation latency, external delivery controls, or the absence of undiscovered bypasses. The principle can be stated without private identifiers, operational settings, or real deal data.", - ], - }, - { - heading: "Expiry and revocation bound the proof", - paragraphs: [ - "A useful permission proof answers enough questions to prevent reuse outside its meaning. It identifies the protected class of resource, the actor or bounded audience, the allowed operation, the tenant context, and the condition under which the decision stops applying. Some grants may end at a stated time; others may remain valid until the seller withdraws a release or a participant leaves the deal. The system should evaluate that context rather than converting proof into an unqualified session-wide privilege.", - "Expiry is not merely cleanup. It makes uncertainty fail closed when a relationship was intentionally temporary. The interface can show that access ended and offer a safe way to request a new decision, but it cannot extend the old grant for convenience. Likewise, a copied link should carry no independent authority. Opening it should lead to a current server-side evaluation, ensuring that the same address can become unavailable when the underlying permission no longer holds.", - "Revocation is credible only if the product knows which derived surfaces might still expose the data. Detail views are the obvious case, but search entries, recent-item lists, previews, notifications, generated exports, and queued work can preserve fragments after the main screen denies access. Insuja's model therefore treats withdrawal as a change that downstream readers must respect, not as a visual toggle. Caches and materialized views need bounded freshness or explicit invalidation so convenience does not silently defeat the seller's decision.", - "A completed external disclosure cannot always be recalled from another person's memory or device, and the product should not promise that fiction. Revocation can stop future service-mediated reads, remove current discovery, and prevent new deliveries within the system's boundary. Clear language about that limit is safer than claiming data has vanished everywhere. The locally observed design supports prospective control; proving actual withdrawal across deployed stores and delivery providers requires environment evidence that this article does not possess.", - ], - }, - { - heading: "Least disclosure shapes every response", - paragraphs: [ - "Permission proofs should authorize only the response needed for the action. A list may reveal a safe label without including a confidential body; a notification may indicate that something changed without copying the protected content; a count may need to exclude inaccessible objects entirely. This discipline reduces the number of places revocation must chase and limits the consequence of a rendering mistake. It also makes policy review concrete because each surface declares what information it intends to disclose.", - "Denials deserve similar restraint. A failed request should not reveal whether another tenant owns the reference, whether a newer private version exists, or which seller action would unlock it. Protected diagnostic evidence can record the evaluated reason for authorized review without echoing the deal itself into routine logs. These requirements appear in first-party design reasoning, but actual observability, retention, and support practices remain private operational concerns whose production quality cannot be certified from a local implementation review.", - ], - }, - { - heading: "Verification follows the revocation graph", - paragraphs: [ - "The right test begins with a legitimate release, observes every permitted surface, revokes the grant, and revisits each surface through both an existing session and a fresh one. It should repeat while a search index is behind, a notification is queued, an export is being prepared, and a browser holds an old page. The goal is not only a denied detail request; it is consistent disappearance or neutralization of every service-controlled derivative without exposing why an unrelated actor was denied.", - "The available private evidence represents sensitive permission as contextual and revocable rather than permanent ambient access. That structure creates a place to express withdrawal and purpose. Measured propagation, failure injection, representative provider behavior, and independent review must then follow the revocation graph in the intended deployment. Operational assurance starts only when every consumer is shown to honor the change.", - ], - }, - ], - relatedSlugs: [ - "insuja-typed-tenant-boundaries", - "insuja-identity-assurance-separation", - "insuja-seller-controlled-releases", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Formal Requests and Q&A as Shared Workflow State", - slug: "insuja-formal-requests-and-qa", - excerpt: - "Insuja turns diligence requests and Q&A into explicit shared workflow state, while keeping each party's private preparation outside the shared record.", - status: "published", - date: "2026-07-04", - category: "Insuja", - project: "insuja", - tags: ["Formal requests", "Shared Q&A", "Workflow provenance"], - placement: "recent", - visual: { - variant: "shared-notebook", - alt: "Animated dither notebook joining a bounded buyer question to a deliberately released seller response", - }, - body: [ - { - heading: "A request is more than a message", - paragraphs: [ - "Diligence can disappear into an inbox when a question, its intended subject, the responsible party, and the accepted answer live in separate messages. Forwarding the thread creates copies without creating shared understanding. Insuja treats a formal request as a first-class workflow object: a bounded question or evidence need that the permitted buyer and seller participants can locate, follow, and move through an explicit lifecycle. Conversation can support the work, but it does not replace the state that says what remains unresolved.", - "Shared request and Q&A activity sit apart from seller-private and buyer-private preparation in the approved local workflow. The boundary is visible enough to discuss without publishing operational identities, deal facts, or provider details. It says nothing about real parties using the workflow in production, live notifications arriving, or every deployed route and search surface preserving the separation.", - ], - }, - { - heading: "A small lifecycle creates shared meaning", - paragraphs: [ - "A request can be newly raised, under review, clarified, answered, or closed without pretending that every workflow needs the same labels. What matters is that transitions have clear actors and preconditions. A buyer can identify an evidence gap, a seller can ask what would satisfy it, and the parties can recognize when a response was formally released. The current state then answers an ordinary question that message history handles poorly: what action is expected now, and from whom?", - "Transitions should not rewrite the record that preceded them. A clarification can narrow the question while preserving why it changed; a replacement answer can supersede an earlier response without making the earlier handoff unknowable; reopening can record that new evidence changed the assessment. This history needs useful timestamps and actors but should avoid copying the full sensitive payload into a broadly readable activity stream. The design makes accountability possible while keeping content access governed by its own permission.", - ], - }, - { - heading: "Shared state still has an audience", - paragraphs: [ - "Calling a workflow shared does not make it public to every participant or every tenant. Each request belongs to a bounded deal context and an intended audience. A buyer's internal draft question can remain buyer-private until it is formally submitted, and a seller's working answer can remain seller-private until it is deliberately released. Once shared, the request state can coordinate the named parties without exposing their private notes, unrelated requests, or material from another opportunity.", - "Permissions must be evaluated on direct reads and changes, not inferred from whether a card appeared on a dashboard. Search, counts, activity summaries, and notifications should expose only the safe fields allowed for the current participant. A notification can identify that action is needed and lead to the authenticated workflow without embedding the answer itself. Those are first-party local design expectations; production provider behavior, recipient mapping, and delivery behavior remain separate verification gates.", - ], - }, - { - heading: "Evidence is released, not attached by accident", - paragraphs: [ - "An answer may refer to seller-controlled material, but mentioning a document does not automatically grant the buyer its bytes. The formal response should identify the bounded evidence subject, while current release and permission decisions govern delivery. That separation keeps workflow state understandable after a document is withdrawn or superseded. It also prevents a convenient attachment field from bypassing the seller's explicit disclosure boundary simply because both objects appear in the same screen.", - "A hypothetical buyer might ask for an updated operating summary. The seller can prepare several private drafts, release one reviewed version as the answer, and later issue a correction. The request history can show that an answer changed, while the buyer sees only versions actually released to that buyer. If access is withdrawn, the service can stop future delivery without falsely promising to erase information already viewed. Clear state and honest limits make the handoff more trustworthy than an opaque file exchange.", - ], - }, - { - heading: "Verification must cross the private and shared edges", - paragraphs: [ - "A representative test should create a buyer-private draft, submit it as a formal request, prepare a seller-private answer, release a bounded response, clarify the request, replace the answer, and close the workflow. At each step, another buyer, an unrelated seller participant, a removed member, and a stale session should fail to discover protected content through direct navigation, search, notifications, or counts. Old links should resolve against current permission rather than preserving yesterday's authority.", - "Insuja's private local record models requests and Q&A as explicit shared workflow state between otherwise separate workspaces. Formal state makes responsibility and provenance legible, but the missing proof is a transition-by-transition run across seller-private, buyer-private, and shared state, including search and notification effects. Production readiness, real-user adoption, deployed isolation, recovery, and independent review all depend on exercising that lifecycle in the intended environment.", - ], - }, - ], - relatedSlugs: [ - "insuja-seller-controlled-releases", - "insuja-buyer-command-workspaces", - "insuja-permission-safe-search-feed", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Permission-Safe Search Starts With Reconciliation", - slug: "insuja-permission-safe-search-feed", - excerpt: - "Insuja treats search as a derived permission-bearing view that must reconcile with authoritative deal state, including releases, revocations, and deletion.", - status: "published", - date: "2026-07-03", - category: "Insuja", - project: "insuja", - tags: ["Search reconciliation", "Permission-aware discovery", "Revocation propagation"], - placement: "stories", - visual: { - variant: "event-river", - alt: "Animated dither event river flowing through a reconciliation grid that removes stale search entries", - }, - body: [ - { - heading: "Search is another disclosure surface", - paragraphs: [ - "A search result can reveal sensitive information before anyone opens its destination. A title, snippet, count, owner label, or timing hint may confirm that a private deal object exists. Insuja therefore treats discovery as part of authorization rather than a neutral convenience layered over protected detail pages. The visible result set must begin with the signed-in actor, tenant context, current deal relationships, and explicit releases, then include only fields suitable for that particular search surface.", - "Permission-aware discovery and reconciliation are deliberate concerns in Insuja's approved local design, especially when shared state changes or disappears. They provide a bounded basis for examining search behavior without revealing a query, customer term, internal service name, or infrastructure topology. The observation does not establish a production index, live feed, measured propagation time, complete deletion, or external provider behavior.", - ], - }, - { - heading: "Query-time filtering is necessary but incomplete", - paragraphs: [ - "Filtering results for the current actor is a crucial final check, yet it cannot repair every unsafe index. A stale document may contain a snippet that should never have been copied, and aggregate counts or suggestions can reveal it even when the main hit is filtered. Indexing should therefore minimize fields, preserve the tenant and resource boundary needed for evaluation, and avoid importing seller-private or buyer-private text unless that search experience has a clear authorized purpose.", - "The product should also resist a common shortcut: trusting a stored audience list forever. Membership changes, releases are withdrawn, questions move between private and shared states, and whole resources can be deleted. Search must evaluate current authority or consume bounded permission state whose freshness is explicit. An old browser view should not make a stale hit usable; opening a result still requires a fresh server-side resource decision. Discovery helps a person navigate, but it never becomes the capability to read.", - ], - }, - { - heading: "Lifecycle updates need reconciliation", - paragraphs: [ - "Creating or releasing a resource may add a discoverable representation. Editing may change its safe title or summary. Revocation should remove it from audiences that no longer qualify, and deletion should remove both the result and any derivative suggestion the product controls. These consequences can arrive asynchronously, so the design needs to acknowledge lag rather than assuming one successful update means every view now agrees. During uncertainty, the safer experience is omission or a neutral unavailable state, not disclosure from a stale copy.", - "Failure is especially visible around retries. The same change may be observed more than once, arrive after a newer change, or be interrupted midway. Applying updates idempotently and comparing their logical order prevents an old release from resurrecting after a withdrawal. Those are general properties of the focused first-party design, not claims about a particular queue or index product. Proving them in operation would require controlled reordering, duplication, interruption, and recovery exercises in the intended environment.", - "Incremental updates make search timely, but no delivery path should be treated as infallible. Reconciliation compares the authoritative set a tenant and permission state should expose with the derived set search currently holds. It can add a missed item, refresh a changed safe representation, and remove an orphan whose source was deleted or whose audience lost permission. The comparison turns silent drift into observable work and provides a recovery path after interruption without requiring operators to guess which individual update vanished.", - "A sound reconciliation pass remains bounded. It should operate within one established tenant and purpose, avoid reading unrelated private payloads merely to calculate presence, and record counts or outcomes without copying sensitive content into logs. Repeated runs should converge on the same result, including deletion, rather than generating duplicates or restoring stale entries. The local design supports this repair model. Production scale, scheduling, provider limits, alerting, and operator response are external facts that this article neither observes nor certifies.", - ], - }, - { - heading: "Test discovery after permission turns backward", - paragraphs: [ - "The revealing test is not whether a newly released item appears. It is whether a once-visible item disappears everywhere it should after access contracts. A representative matrix should withdraw a seller release, remove a buyer member, return a shared question to a private draft when policy allows, and delete a resource. It should then inspect exact search, prefixes, suggestions, counts, recent items, direct links, stale sessions, duplicated updates, skipped updates, and a later reconciliation pass.", - "Private evidence supports search as a permission-bearing derived view and reconciliation as a first-class response to drift. Production isolation, deletion guarantees, propagation targets, provider resilience, and independent adversarial review remain outside that observation. Query checks protect the present request; a demonstrated reconciliation run is what would show the derived history can recover after diverging from authoritative state.", - ], - }, - ], - relatedSlugs: [ - "insuja-typed-tenant-boundaries", - "insuja-revocable-permission-proofs", - "insuja-formal-requests-and-qa", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Repository Access Should Begin With an Explicit Yes", - slug: "hyoka-opt-in-repository-access", - excerpt: - "A local assistant should enter a repository only after a person chooses that scope, can see what was granted, and can withdraw it without confusing project access with broader machine authority.", - status: "published", - date: "2026-07-02", - category: "Hyoka Hanesu", - project: "hyoka-hanesu", - tags: ["Repository consent", "Visible scope", "Local tools"], - placement: "research", - visual: { - variant: "local-orbit", - alt: "Animated dither orbit closing around a deliberately selected repository boundary", - }, - body: [ - { - heading: "Opening a project should be a consent event", - paragraphs: [ - "A repository assistant is most useful when it can read enough of a project to answer concrete questions, yet that usefulness does not justify ambient reach across a machine. The first meaningful action should be a person selecting the project they intend to discuss. That moment establishes a visible boundary between the chosen material and everything else nearby. Hyoka Hanesu treats this as part of the product conversation: access begins with a deliberate yes, not with a scan that asks forgiveness after private material has already entered the session.", - "An explicitly chosen project organizes the approved local workflow, joining consent and scope at the start of a session. That design observation can be shared without repository contents, machine locations, credentials, or provider settings. It cannot demonstrate operating-system containment, protection from every possible tool misuse, or a distributed build behaving identically on another machine. Those environment questions remain private and open, and the limit matters as much as the design idea.", - ], - }, - { - heading: "The granted scope must stay legible", - paragraphs: [ - "A file picker alone is not a durable explanation of authority. Once a project is open, the interface should continue to identify the selected scope in human language and make project changes conspicuous. A stale title, remembered conversation, or recent-project shortcut must not leave someone wondering which material the assistant can currently inspect. Legibility also improves error handling: when a request depends on content outside the selected boundary, the product can explain that limitation instead of quietly widening its search or returning a mysterious partial answer.", - "The safest default for missing or invalid scope is to stop project work while preserving enough interface state to let the person choose again. That failure should not fall back to a broader directory, an earlier project, or an implicit development location. This is a design rule recorded from local first-party work, not proof that every indirect reference, linked resource, or platform-specific edge case has been contained. Boundary-escape exercises and representative packaging tests would still be required before making a stronger public security statement.", - ], - }, - { - heading: "Project consent is not blanket tool consent", - paragraphs: [ - "Choosing a repository answers where the assistant may gather project context; it does not automatically answer what every tool may do. Reading a selected file, proposing a patch, changing a file, starting a process, or contacting a remote service carry different consequences. A predictable assistant makes those differences visible and places additional confirmation around actions that create side effects. The repository boundary should constrain each operation, while the operation itself remains subject to its own explanation and approval when the consequence deserves one.", - "This separation prevents a convenient phrase such as ‘open this project’ from becoming an invisible grant for unrelated machine activity. It also gives the person a useful mental model: project selection bounds context, tool policy bounds actions, and backend choice bounds where processing occurs. The reviewed design direction supports that layered model locally. It does not establish that hostile instructions cannot manipulate a tool, that every platform API honors the intended boundary, or that a production-grade sandbox has been independently assessed.", - ], - }, - { - heading: "Consent needs a lifecycle, not a checkbox", - paragraphs: [ - "A useful grant can outlive the screen where it was made, so persistence must be deliberate. Reopening a recent project may be helpful, but the interface should distinguish remembered selection from an active session and provide a clear way to close or replace it. Changing projects should invalidate assumptions tied to the earlier context, including cached excerpts and pending actions. Otherwise a conversation can display one project while an old tool request still points at another, turning a reasonable convenience into an authority mismatch.", - "Revocation should be equally ordinary. Closing the project or clearing its session should stop new context gathering and remove retained material according to the product's stated local policy. That statement is intentionally normative: this public journal does not expose private retention details or claim that every temporary copy has been forensically removed. Demonstrating complete cleanup would require platform-specific observation across interruptions, crashes, restarts, and updates. The local design review only supports the decision that withdrawal must be treated as behavior, not decorative interface text.", - ], - }, - { - heading: "Negative cases are the next credible proof", - paragraphs: [ - "The most informative access tests begin outside the happy path. A useful review would open one project, request material from another, switch projects during an unfinished action, restore a session after the project moved, and attempt operations through indirect references. The expected result should remain narrow and intelligible: no silent widening, no reuse of stale authority, and a clear route back to an explicit choice. Accessibility belongs in that proof as well, because consent that cannot be understood or reversed with a keyboard is not meaningful consent.", - "Passing local cases would still be only one rung in the evidence ladder. Public distribution needs clean-machine installation, operating-system permission review, update and uninstall behavior, representative user testing, and independent examination of boundary failures. Hyoka Hanesu currently explores repository access as an explicit, visible product decision. Notarization, universal containment, production reliability, and safety against every misuse of an authorized tool require evidence beyond the private prototype.", - ], - }, - ], - relatedSlugs: [ - "hyoka-context-budgets", - "hyoka-provider-boundaries", - "gy-git-trust-boundaries", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Building at Git Trust Boundaries in Assembly", - slug: "gy-git-trust-boundaries", - excerpt: - "An assembly Git prototype makes every length, delimiter, file transition, and process boundary consequential, so parsing limits and interoperability must be visible design commitments.", - status: "published", - date: "2026-06-29", - category: "gy", - project: "gy", - tags: ["Git boundaries", "Bounded parsing", "Assembly research"], - placement: "stories", - visual: { - variant: "terminal-rain", - alt: "Animated dither terminal stream passing through bounded Git parsing gates", - }, - body: [ - { - heading: "Assembly removes comforting ambiguity", - paragraphs: [ - "A high-level Git client can still mishandle input, but its libraries usually hide many decisions about allocation, strings, processes, and file access. An assembly prototype meets those decisions directly. Every incoming length needs a destination, every delimiter needs a search bound, and every borrowed convention needs an explicit failure path. That pressure is valuable research because it makes trust boundaries difficult to ignore. It is also dangerous if small successful examples are mistaken for broad compatibility or memory safety before the surrounding assumptions have been challenged.", - "gy's approved private research record treats parsing and runtime boundaries as first-class questions while investigating Git and forge behavior. This entry publishes no source location, machine detail, unpublished test artifact, infrastructure value, or operational identifier. The local observation supports the research framing, not a qualified release, compatibility with all Git behavior, or protection against hostile input. Reproducible public evidence and independent scrutiny would be needed for those stronger conclusions.", - ], - }, - { - heading: "Parsing and runtime both begin with bounded trust", - paragraphs: [ - "Git-shaped input arrives through configuration, references, object metadata, packetized exchanges, command arguments, and files whose contents may be larger or stranger than a friendly fixture. A bounded implementation decides maximum lengths, valid character sets, termination rules, and arithmetic behavior before copying or advancing a pointer. It rejects incomplete and oversized input without using a partial value as authority. The goal is not to accept every possible form; it is to make the accepted subset deliberate and ensure refusal does not corrupt state or expose unrelated memory.", - "A parser budget also needs composition. Two individually bounded fields can still overflow a shared buffer when combined, and a valid count can become unsafe after multiplication or alignment. End-of-input, embedded separators, repeated headers, and conflicting declarations deserve explicit outcomes. The design journal records this discipline as intent and local work, not as formal proof. Sanitized fixtures and focused tests can demonstrate named cases, but comprehensive hostile-input confidence would require fuzzing, instrumentation, architecture review, and a maintained account of the formats gy intentionally does not support.", - "A prototype often succeeds while launched from its development checkout because templates, static assets, and helper data happen to be nearby. An installed command runs under a different working directory and should not depend on the caller standing in a particular place. It needs a clear rule for locating its own packaged resources, distinguishing user configuration from immutable assets, and failing safely when either is absent. That is a trust boundary because an uncontrolled working directory must not replace trusted program material merely by containing a familiar filename.", - "Configuration follows the same principle. Environment values and files are untrusted inputs even when they were written by the same person earlier. The program should parse only the options it understands, apply a documented precedence, and avoid turning an empty or malformed value into a broad filesystem target. These are public-safe design requirements, not a disclosure of gy's private layout. Local install exercises can support them on one candidate build, but packaging across clean systems and upgrade or removal behavior remains separate proof.", - ], - }, - { - heading: "Interoperability lives between implementations", - paragraphs: [ - "Producing bytes that resemble Git output is not the same as interoperating with the wider ecosystem. Another implementation may order fields differently, omit an optional marker, advertise an unfamiliar capability, split a response at another boundary, or reject a shortcut tolerated by a local fixture. gy therefore needs tests that exchange real artifacts with independent implementations and compare semantic results, not only snapshots of its own output. The boundary includes failure behavior: an unsupported feature should be named and refused without leaving a misleading partial repository state.", - "Networked forge behavior widens the matrix further through redirects, authentication challenges, interrupted transfers, retries, and responses that are syntactically valid but semantically inconsistent. This article does not claim live service compatibility or reproduce private endpoint information. It argues that reference-client round trips, hermetic local peers, and explicitly approved external checks answer different questions and should remain labeled. A green hermetic exchange proves a useful contract; it cannot by itself establish current interoperability with every remote service or configuration.", - ], - }, - { - heading: "The boundary report should include what failed", - paragraphs: [ - "Research becomes credible when unsupported and failing cases are recorded beside successful ones. A useful gy qualification report would list accepted input envelopes, rejected forms, independent round trips, interruption behavior, installed-runtime checks, and any profile that could not run in the available environment. It should preserve enough deterministic detail for another reviewer to repeat the public cases without revealing private machine state. Accessibility and presentation also matter for any served interface, but a polished screen must remain separate from the correctness of the Git operations behind it.", - "The next proof should combine bounded-parser tests, generated malformed inputs, independent interoperability, clean installation, resource lookup from unrelated working directories, failure recovery, and outside review. ‘Research prototype’ remains the evidence-aligned status while those gates are open. Assembly exposes assumptions with unusual clarity; it does not automatically remove them. Memory safety, universal Git compatibility, production suitability, external review closure, and a qualified gy release all require publishable results from that broader matrix.", - ], - }, - ], - relatedSlugs: [ - "gy-qualification-before-release", - "hyoka-opt-in-repository-access", - "requisia-private-object-delivery", - ], - verifiedAt: "2026-07-17", - }, - { - title: "Qualification Evidence Before Release Language", - slug: "gy-qualification-before-release", - excerpt: - "A research prototype earns stronger release language only when build, conformance, interoperability, packaging, recovery, and independent-review evidence are reported as separate gates.", - status: "published", - date: "2026-06-28", - category: "gy", - project: "gy", - tags: ["Release qualification", "Evidence gates", "Prototype status"], - placement: "research", - visual: { - variant: "cost-contours", - alt: "Animated dither signal window separating prototype milestones from release qualification", - }, - body: [ - { - heading: "Progress and release answer different questions", - paragraphs: [ - "A prototype can compile, complete a compelling scenario, and teach its author something important without being ready for other people to rely on. Those accomplishments answer whether the idea works under known conditions. Release language answers a broader question: can a defined artifact be installed, exercised, diagnosed, updated, and removed across its supported environment with known limitations? gy benefits from preserving that distinction because an assembly implementation can look dramatically complete in a narrow demonstration while still carrying untested assumptions at every external boundary.", - "The approved record supports two limited statements: gy has meaningful private research progress, and qualification is an explicit concern. Private source, machine details, phase records, infrastructure values, and unpublished results stay outside the entry. Local evidence is not promoted into release status; strict profiles are not said to pass, production suitability is not asserted, and independent review is not presented as complete. The purpose here is to describe the evidence structure required before stronger language becomes responsible.", - ], - }, - { - heading: "Qualification is a stack of named gates", - paragraphs: [ - "The first gate establishes a reproducible build from declared inputs. Focused tests then exercise bounded units and failure cases. Conformance checks compare behavior with written requirements, while interoperability exchanges artifacts with an independent implementation. Packaging proves that the candidate carries the resources it needs outside a development checkout. Installation and removal verify the supported lifecycle on a clean target. Recovery exercises interruptions and retries. Each gate narrows a different uncertainty, so one green layer should never silently stand in for the layers above it.", - "A useful report records the candidate identity, environment class, commands or procedures, expected result, observed result, and disposition for every gate. Public evidence must remain sanitized and reproducible; private operational data is neither necessary nor appropriate. ‘Not run’ and ‘blocked’ are valid outcomes when stated plainly. They are not failures to be hidden, and they are not passes. This separation lets future work resume at the actual open boundary instead of rebuilding confidence from a summary that flattened several kinds of evidence into one optimistic status.", - ], - }, - { - heading: "A clean environment challenges hidden dependencies", - paragraphs: [ - "Development machines accumulate compilers, helper tools, environment values, cached assets, and familiar working directories. A candidate that succeeds there may depend on state absent from the intended target. Qualification therefore needs a clean, representative environment created from the published prerequisites. The artifact should start from an unrelated working directory, locate only its packaged resources and documented configuration, reject missing requirements clearly, and leave the system in a known state after removal. Repeating the lifecycle reveals assumptions that an in-place run cannot see.", - "Architecture and operating-system boundaries matter just as much. A build produced on one machine may target another runtime, so inspecting the artifact and exercising it in the intended environment answer different questions. Emulation can provide useful evidence when labeled, but it does not automatically replace native-host behavior. The private gy work may include local candidates and constrained test environments; this journal does not turn those into distribution proof. Supported-platform qualification still requires clean evidence for the exact artifact and lifecycle being described.", - ], - }, - { - heading: "Strict profiles should fail closed", - paragraphs: [ - "A qualification profile is valuable only when its prerequisites and success criteria are explicit. If a required host, independent peer, security instrument, or review artifact is unavailable, the profile should stop with a precise blocked outcome. Substituting a lighter check may help diagnose progress, but it creates a different evidence class and must receive a different label. This is especially important for low-level work, where a normal functional run cannot establish memory safety, malformed-input resilience, or conformance at the edges of the accepted format.", - "Failures should retain actionable context without leaking private machine or service information. The report can identify the gate, expected capability, sanitized symptom, and next proof needed. It should not publish credentials, internal locations, provider identifiers, or mutable operational notes. Local remediation followed by a rerun can close the named case, but it does not retroactively validate unrelated profiles. The reviewed design posture favors that fail-closed accounting; public confidence still depends on seeing repeatable results from the eventual candidate rather than trusting an unpublished private ledger.", - ], - }, - { - heading: "Release language is the final decision gate", - paragraphs: [ - "Once the evidence stack is complete, release wording should name the supported scope and remaining limitations rather than declaring the prototype simply ‘ready.’ A responsible handoff can state which artifact was qualified, on which environment class, against which interoperability peers, with which lifecycle and recovery cases. It can also say what was excluded. That precision makes a smaller release more trustworthy than a broad promise. Versioning, checksums, licensing, public documentation, and an accessible issue path belong in this final gate because distribution creates responsibilities beyond code execution.", - "Describing the threshold does not mean gy has crossed it. The next credible step is a candidate-specific qualification packet reviewed by someone other than the implementer, followed by publication only when required gates pass or remaining exclusions are explicitly accepted. ‘Research prototype’ remains the status. A qualified release, production suitability, universal compatibility, memory-safety proof, strict-profile completion, and external security closure all await candidate-specific evidence.", - ], - }, - ], - relatedSlugs: [ - "gy-git-trust-boundaries", - "requisia-composite-readiness", - "hyoka-provider-boundaries", - ], - verifiedAt: "2026-07-17", - }, -]; - -export const FOCUSED_POSTS: readonly PublishedPost[] = [...JOURNAL_POSTS].sort( - (left, right) => right.date.localeCompare(left.date), -); diff --git a/src/content/posts.json b/src/content/posts.json new file mode 100644 index 0000000..5701375 --- /dev/null +++ b/src/content/posts.json @@ -0,0 +1,1236 @@ +[ + { + "title": "Organization-Scoped Registers Without Spreadsheet Amnesia", + "slug": "requisia-organization-scoped-registers", + "excerpt": "Requisia treats the familiar workbook as an exchange surface around an organization-scoped register, preserving identity, field meaning, and revision history when the table changes shape.", + "status": "published", + "date": "2026-07-17", + "category": "Requisia", + "project": "requisia", + "tags": [ + "Register identity", + "Schema revisions", + "Controlled fields" + ], + "placement": "featured", + "visual": { + "variant": "record-lattice", + "alt": "Animated dither lattice in which register rows keep their identity while columns shift" + }, + "body": [ + { + "heading": "A table can remember more than its cells", + "paragraphs": [ + "Procurement work often begins in a workbook because a table is quick to read, easy to circulate, and flexible enough for an unexpected field. The weakness appears later: two rows can look identical while representing different obligations, and a renamed column can quietly change the meaning of years of history. Requisia approaches that problem by treating the register as the durable product object and the workbook as one useful view of it. That distinction preserves the familiarity of rows and columns without asking the file to carry every rule by itself.", + "The public account here is limited to concepts approved from private implementation and product contracts: fields, records, templates, and the selected Current workbook are separate concerns. A record keeps a stable identity while visible values change; a field gives a column explicit meaning; a template shapes an exchange format; and Current points to an accepted version. That separation supports the design discussion, but an anonymous reader cannot reproduce the underlying implementation observation. It proves nothing about production organization setup, historical migration, or a customer workflow passing live verification." + ] + }, + { + "heading": "Organization scope comes before the row", + "paragraphs": [ + "A register row is not meaningful in isolation. The same supplier name, reference number, or status label can legitimately exist in two organizations with different histories and owners. Requisia therefore makes organization scope part of the server-side decision before a record is read or changed. The browser may name the record a person wants to open, but it cannot decide which organization owns it. This ordering matters because a perfectly valid identifier from one workspace must remain useless in another, even when both people arrived through the same visual interface.", + "The model also avoids a hidden universal workspace. Defaults feel convenient during development, yet they turn missing context into accidental access when a request reaches the wrong path. A scoped register instead requires the application to resolve the signed-in actor, organization, register, and permitted action from trusted state. That is a design boundary, not a claim that isolation has been proven under production traffic. Public confidence would require representative sessions, cross-organization negative tests, role changes, and provider evidence that is deliberately outside this journal entry." + ] + }, + { + "heading": "Fields and revisions make collisions visible", + "paragraphs": [ + "When a field is only a label above a cell, every importer and screen can interpret it differently. Requisia gives fields a more serious job: they connect the application property to the workbook column and can carry controlled choices or other validation expectations. A field change is therefore a schema decision rather than a cosmetic edit. That makes it possible to explain why an old workbook needs review, why an unfamiliar value was rejected, or why a column cannot simply vanish while records still depend on its meaning.", + "This separation also clarifies permissions. Editing a record value, changing the register schema, hiding a field, deleting a record, and permanently purging a field do not have to be the same authority. A person trusted to update an order status need not be able to redefine the status vocabulary for everyone. The reviewed materials make those distinctions visible in the product contract. They are local first-party evidence that the rules were intended and implemented; only a live role matrix and audit review could show that every deployed route enforces them consistently.", + "Flexible tables invite parallel work. One operator adjusts a controlled list while another edits a record against the old list; a third person imports a workbook exported earlier that morning. Silently accepting all three creates spreadsheet amnesia: the final table exists, but nobody can explain which assumptions survived. Requisia uses separate data and schema revisions so a mutation can declare the state it was based on. If that state is stale, the system can stop and ask for a fresh view rather than inventing a merge behind the operator's back.", + "A rejection is useful only when it remains legible. The interface should say that the underlying register changed, preserve the person's attempted work where safe, and offer a path to compare or retry. It should not expose private identifiers, internal storage details, or another organization's values while explaining the conflict. The current design supports this fail-closed direction, but the journal cannot certify the full experience. Concurrent edits, controlled-list changes, interrupted imports, and recovery after a rejected write still need repeatable environment-level evidence before anyone calls the behavior operationally complete." + ] + }, + { + "heading": "The workbook stays useful by losing authority", + "paragraphs": [ + "None of this is an argument against Excel. It is an argument for giving the workbook a precise role. People can sort, review, annotate, and exchange a bounded representation while the register retains stable identities, schema meaning, and revision history. Export becomes a deliberate snapshot; import becomes a proposed change; and a generated file cannot quietly overwrite the accepted current version. The result is a gentler product because familiar tools remain available while the system, rather than human memory, carries the rules that make repeated exchange safe.", + "A complete organization-level lifecycle is the next credible proof: define fields, create records, export, edit, preview an import, resolve a conflict, accept a version, restore an earlier state, and confirm that another organization cannot observe any step. Someone other than the original implementer should run it and record outcomes without publishing business data. The private work currently supports the register boundary as a local design. Production readiness, deployment state, migration success, and customer use remain separate questions with no evidence supplied here." + ] + } + ], + "relatedSlugs": [ + "requisia-preview-before-apply", + "requisia-current-workbook-pointer", + "insuja-typed-tenant-boundaries" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Preview Before Apply: Making Excel Imports Reversible", + "slug": "requisia-preview-before-apply", + "excerpt": "A workbook upload can alter hundreds of procurement records at once, so Requisia separates bounded parsing, an intelligible preview, and a revision-aware transactional apply.", + "status": "published", + "date": "2026-07-16", + "category": "Requisia", + "project": "requisia", + "tags": [ + "Import preview", + "Merge semantics", + "Replace confirmation" + ], + "placement": "recent", + "visual": { + "variant": "paper-field", + "alt": "Animated dither sheets separating into parse, preview, and apply stages" + }, + "body": [ + { + "heading": "An upload is a proposal, not a command", + "paragraphs": [ + "A normal form usually changes one small object that a person can see. A workbook may carry hundreds of rows, removed values, reordered columns, and references created before the latest register edit. Treating that file as a large form submit hides the scale of the decision. Requisia instead frames an upload as a proposal. The system first establishes whether the file is bounded and intelligible, then describes the proposed changes, and only later accepts an explicit decision to apply them. The pause is part of the product, not friction around it.", + "Four stages bound what can be described from the approved local evidence: workbook parsing, preview generation, merge-or-replace intent, and apply. Stable record identity also matters more than visible row order. Those observations establish an implementation direction without establishing compatibility with an arbitrary production workbook. No customer file, live provider configuration, or deployed database supports this entry; readers should understand that missing environment evidence as a deliberate limit rather than assume the preview has already survived every operating condition." + ] + }, + { + "heading": "Bound the file before doing durable work", + "paragraphs": [ + "The safest import is one that can refuse unreasonable input before it consumes unbounded time or creates partial state. Byte and row limits give the parser a known envelope. Column recognition, required values, controlled choices, and stable identities can then be evaluated without writing to the register. A malformed file should produce a useful, bounded explanation rather than a half-imported table. This protects both the operator's intent and the service from a document whose size or shape is different from what the product promised to handle.", + "Validation must also respect the register's current schema. A workbook exported under yesterday's fields cannot redefine today's controlled list merely because its header looks familiar. The preview can identify unknown columns, invalid choices, duplicate identities, or missing requirements and show where the proposal diverges. It should never echo unrelated private values into logs or error telemetry. The reviewed implementation contract supports early limits and authoritative schema rules; broad format compatibility, hostile-file behavior, and provider resource limits remain tests to run in the intended environment." + ] + }, + { + "heading": "Merge and replace answer different questions", + "paragraphs": [ + "Merge asks how the proposed workbook changes known records while retaining other register state. Stable identities allow an edited row to remain the same record even when its label or position moves. New rows can be named as additions, changed cells as updates, and missing rows as unchanged unless the chosen operation says otherwise. This makes the preview conversational: it can tell the operator what will happen in the vocabulary of the register rather than presenting a raw diff that only an implementer can interpret.", + "Replace asks a much stronger question: should this workbook become the complete register, including the consequences of omissions? That intent deserves a fresh preview and an exact confirmation tied to the relevant module and proposal. A generic modal saying 'Are you sure?' does not communicate the scope. The design described in Requisia keeps merge and replace distinct so convenience cannot silently escalate authority. The public article records that design; it does not claim every deployed interface, API client, or retry path has been observed enforcing it." + ] + }, + { + "heading": "A preview expires when its assumptions change", + "paragraphs": [ + "Between preview and apply, another person may edit a record or adjust the schema. Applying the old proposal as though nothing changed would turn the preview into theatre. Requisia binds the operation to the data and schema revisions it examined. When either has moved, the safer response is to stop and regenerate the preview against current state. The operator can then see whether the proposed change still means the same thing, rather than relying on an obsolete picture that happened to remain open in a browser tab.", + "Transactional apply provides the other half of reversibility. The accepted mutation should complete as one coherent register decision or leave the prior authoritative state intact; an interruption must not produce an unexplained mixture of old and new rows. That principle is visible in the reviewed roadmap and focused contracts. Production confidence would require deliberately interrupted applies, concurrent edits, retry exercises, database failure simulation, and a verified recovery path. Those exercises are not replaced by a passing parser test or a polished preview screen." + ] + }, + { + "heading": "Human review is part of the data model", + "paragraphs": [ + "A strong preview shows meaning, not just volume. Counts help, but an operator also needs to distinguish additions, updates, invalid values, and destructive omissions; locate the affected records; and understand which rules produced a warning. The screen should keep keyboard navigation, readable contrast, and a durable way to revisit the decision. When the proposed change is large, the product should make caution easier than reflex. That is how a bulk workflow can remain comprehensible without pretending automation eliminated human responsibility.", + "A useful proof set would cover a small valid merge, a deliberate replace, a stale preview, a malformed file, a large valid file, a controlled-list conflict, an interrupted apply, and a safe retry. It should verify both register results and the operator-facing explanation while keeping real business data out of public evidence. Requisia's local design makes import reversible in structure and intent; production scale, live database behavior, recovery, and the correctness of any organization's uploaded workbook are still unverified." + ] + } + ], + "relatedSlugs": [ + "requisia-organization-scoped-registers", + "requisia-current-workbook-pointer", + "requisia-composite-readiness" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Current Is a Pointer, Not a Convenient Regeneration", + "slug": "requisia-current-workbook-pointer", + "excerpt": "Requisia gives the accepted Current workbook an explicit version pointer, so a newly generated file cannot silently impersonate the artifact people have chosen to rely on.", + "status": "published", + "date": "2026-07-15", + "category": "Requisia", + "project": "requisia", + "tags": [ + "Current pointer", + "Workbook versions", + "Checksum history" + ], + "placement": "stories", + "visual": { + "variant": "archive-lines", + "alt": "Animated dither archive with one illuminated pointer selecting an accepted workbook version" + }, + "body": [ + { + "heading": "The word current needs a contract", + "paragraphs": [ + "A download button labeled Current looks simple, yet it can hide two incompatible meanings. It might return the last workbook a person accepted, or it might regenerate a fresh file from whatever the database contains now. Those files can differ at exactly the moment someone needs certainty. Requisia defines Current as an authoritative pointer to a private, versioned workbook. Generation remains useful, but it creates a candidate or a new version; it does not rewrite the meaning of Current merely because producing another spreadsheet is technically easy.", + "Template state, generated workbooks, accepted versions, version metadata, and the Current pointer appear separately in the approved product record. Checksums identify the bytes associated with a version instead of trusting a mutable filename. That private observation can support a public discussion of the boundary, not a reproducible implementation review. It leaves open whether a production pointer exists, every historical object is recoverable, or any deployed download has been checked against a live storage provider." + ] + }, + { + "heading": "Version history makes missing state honest", + "paragraphs": [ + "A procurement workbook is often both a working surface and a handoff artifact. If every UI edit simply regenerates the same path, a later reviewer cannot tell whether a difference came from an accepted import, an application edit, a template update, or a background process. Versioning creates room for that explanation. Each accepted artifact can retain its own metadata and checksum, while a deliberate pointer update says which version the organization currently recognizes as authoritative.", + "History is valuable only if it cannot be revised casually. Creating a new version should not alter the bytes or identity of an earlier one, and selecting Current should be a separate decision from generating a file. That lets an operator inspect a candidate, reject it, or move the pointer back when policy permits. The local contract makes these decisions distinct. It is not yet public proof of retention duration, object durability, rollback permissions, or the consistency of pointer changes under concurrent production use.", + "When the Current pointer is absent, the tempting fallback is to generate a workbook and return it so the button still appears to work. That response invents authority. The resulting bytes may be accurate as a projection of current records, but nobody selected them as the accepted artifact. Requisia treats a missing pointer as an explicit state the interface must explain. The user can then create or select a version through the intended workflow instead of receiving a convenient file with a misleading name.", + "The same principle applies when the pointer targets unavailable bytes or a checksum does not match. A bounded error should preserve the distinction between metadata and object availability, avoid exposing provider paths, and give an operator a recovery starting point. It should not redirect silently to a different version. The design material names checksum verification and private version handling, but actual failure behavior remains an environment question. Missing objects, corrupted bytes, provider outages, and permission changes require controlled tests before the system can make an operational reliability claim." + ] + }, + { + "heading": "Download authority is evaluated at request time", + "paragraphs": [ + "Knowing the Current version does not grant access to it. A download still has to resolve the signed-in actor, organization, relevant module, permitted assignment, chosen version, and private object metadata. Browser-visible identifiers are references that help ask for a resource; they are not capabilities that bypass the current authorization decision. This matters when someone bookmarks a link, changes roles, or loses an assignment after the link was first shown.", + "A safe delivery path also keeps storage details on the server and streams only after the full decision succeeds. Email can point a recipient toward a signed-in destination without embedding the private file itself. These are high-level properties of the reviewed private implementation, not a disclosure of its topology. This note cannot show that session expiry, assignment revocation, parallel downloads, or partial streams behave correctly in production. Those claims need direct evidence from the intended runtime and real authorization configuration." + ] + }, + { + "heading": "A useful lifecycle closes the loop", + "paragraphs": [ + "The strongest workbook story begins before download and ends after recovery. An organization defines its register, generates a candidate, reviews it, accepts a version, downloads exactly those bytes, makes a later change, accepts another version, and can still inspect the earlier artifact. Pointer history should explain which decision moved Current and when, without placing customer content or credentials in public logs. That sequence turns a collection of files into an accountable operating workflow.", + "Verification should deliberately test failed regeneration, concurrent pointer changes, checksum mismatch, missing objects, authorized rollback, retention, backup restoration, and access from the wrong organization. A public-safe record can report which boundary passed without publishing the workbook. The reviewed local design gives Current a durable meaning and avoids silent regeneration. Production storage, recovery, availability, and the state of any customer's accepted artifact stay outside that design-level finding." + ] + } + ], + "relatedSlugs": [ + "requisia-organization-scoped-registers", + "requisia-preview-before-apply", + "requisia-private-object-delivery" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Portal Visibility Is Not Document Authority", + "slug": "requisia-portal-and-document-assignments", + "excerpt": "Requisia separates the assignment that makes business work visible in a portal from the narrower, current authorization required to deliver a private document.", + "status": "published", + "date": "2026-07-14", + "category": "Requisia", + "project": "requisia", + "tags": [ + "Portal assignments", + "Document grants", + "Recipient isolation" + ], + "placement": "research", + "visual": { + "variant": "contract-bridge", + "alt": "Animated dither bridge showing separate portal visibility and private document authorization lanes" + }, + "body": [ + { + "heading": "Seeing the work is not receiving the file", + "paragraphs": [ + "A client or vendor portal needs to reveal enough context for a person to understand what requires attention. That visibility may include an RFQ, order, invoice, report, or another register record. It does not follow that every attachment connected to the visible record should be downloadable. Requisia models these as two assignments: one makes the relevant business object available in the portal, while another represents the active authorization for a specific private document. The separation prevents a broad workspace view from becoming an accidental file-sharing capability.", + "Portal assignments and document assignments appear as different product objects in Requisia's approved private notes, with separate revocation and delivery concerns. Preserving that reasoning publicly does not require exposing recipients, object locations, or operational identifiers. The evidence boundary stops at the reviewed product distinction: it cannot show that a production portal is configured, a real recipient has been invited, or every deployed download route currently performs the intended checks." + ] + }, + { + "heading": "Assignments describe purpose as well as identity", + "paragraphs": [ + "A portal assignment answers why an external party can see a piece of work: perhaps a vendor is responding to a package, or a client is reviewing a report. That purpose shapes the fields and actions appropriate to the view. A document assignment answers a narrower question: may this signed-in recipient receive these private bytes now? Keeping the questions separate makes it possible to show a record after an attachment has been revoked, or share one attachment without exposing every file related to the same business entity.", + "This also improves interface clarity. A visible row can show that a document exists without presenting an active download action when the grant is absent, expired, or revoked. The screen does not have to pretend that all missing authority is a missing record. Conversely, a direct request for a private object cannot rely on the fact that the surrounding page once rendered. These behaviors are design expectations from local work; a full browser and direct-request matrix is still necessary to show they hold across real sessions and deployment boundaries." + ] + }, + { + "heading": "The session defines the recipient", + "paragraphs": [ + "A client-supplied recipient field is not proof of who is making a request. Requisia derives the actor and organization from the signed-in session, then evaluates the active assignment for that context. The requested record or document identifier merely names what the person wants. This ordering resists a common failure mode in multi-party systems: changing a visible identifier until another organization's resource appears, even though the surrounding route and interface look normal.", + "Notifications follow the same boundary. A message can announce that new work is available and lead to a login destination, while private delivery remains behind the current session and assignment decision. Sending a durable object URL in email would freeze authority at message time and make later revocation unreliable. The reviewed material establishes that Requisia intends authenticated delivery rather than clever links. It does not prove deliverability, session behavior, or revocation timing with production providers, all of which remain external evidence gates." + ] + }, + { + "heading": "Revocation must survive old links", + "paragraphs": [ + "People bookmark pages, forward messages, and leave tabs open. A meaningful revocation therefore cannot depend on hiding a button or removing a portal card. The server must re-evaluate the document assignment when the bytes are requested. If the grant no longer applies, the old reference stays a reference and yields no file. The product may still explain that access changed, but that explanation must avoid confirming private metadata to someone who is no longer an authorized recipient.", + "Assignment changes can race with active sessions or a stream already in progress, so the operational policy needs precision about when revocation takes effect. Different choices may be reasonable, but they should be documented, tested, and visible to operators. The local design gives revocation first-class status; this article cannot validate every timing edge. Direct URL replay, session expiry, recipient reassignment, parallel requests, and an interrupted stream require controlled environment tests rather than inference from a static permission check." + ] + }, + { + "heading": "Prove both halves of the boundary", + "paragraphs": [ + "A representative journey should assign portal work to one external party, expose only the permitted fields, attach a private document through its own grant, deliver it after authentication, revoke that grant, and confirm that the surrounding business record remains visible if policy allows. A second organization and a different recipient should fail at both the interface and direct-request layers. Audit evidence should record decisions without copying private document content into an easier-to-leak channel.", + "Real client and vendor sessions, session expiry, assignment updates, recipient changes, old links, and provider failure all belong in that journey. Local tests or service-boundary review establish only a part of it. What the available design shows is independent modeling of portal visibility and document delivery, a useful foundation for least authority. Production isolation, customer access, notification delivery, and live revocation still need direct environment evidence." + ] + } + ], + "relatedSlugs": [ + "requisia-rfq-package-contract", + "requisia-private-object-delivery", + "insuja-seller-controlled-releases" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "RFQ Packages Without a Shadow Source of Truth", + "slug": "requisia-rfq-package-contract", + "excerpt": "Requisia composes an RFQ package from the existing register record, a targeted portal assignment, and separately authorized attachments instead of creating a second drifting database.", + "status": "published", + "date": "2026-07-13", + "category": "Requisia", + "project": "requisia", + "tags": [ + "RFQ composition", + "Field visibility", + "Attachment separation" + ], + "placement": "build-business", + "visual": { + "variant": "handoff-map", + "alt": "Animated dither map assembling an RFQ record, portal view, and separately gated attachments" + }, + "body": [ + { + "heading": "A package should not become a second procurement system", + "paragraphs": [ + "An RFQ package looks like a distinct product object because it has a recipient, a deadline, visible fields, and attachments. The easy implementation is to copy all of that into a special package store. The copy works at first, then begins to drift: a status changes in the register but not the package, a supplier name is corrected in one place, or a withdrawn attachment remains reachable from the other. Requisia avoids that shadow source of truth by composing the package around the existing vendor-RFQ register record.", + "Stable record identity, portal-visible fields, a targeted assignment, and separately granted private documents form the package in the approved local contract. Explaining that composition keeps the authoritative data boundary intelligible without reproducing private source. The contract is evidence of implementation direction only. It cannot demonstrate that a production RFQ has been issued, a vendor has received one, or live portal and storage configuration enforce every intended boundary." + ] + }, + { + "heading": "Composition defines the disclosure", + "paragraphs": [ + "When the RFQ remains a register record, ordinary register rules continue to apply. Its stable identity survives a label edit, controlled fields keep their defined meanings, and a revision can expose when someone is acting on an older view. The portal does not need to invent a parallel status vocabulary. It can present a purpose-built view of the same business object, limited to the fields appropriate for the assigned vendor and the stage of the workflow.", + "This is more than data normalization. One source of truth creates a clearer conversation between internal operators and external participants: a correction is a register decision, portal visibility is an assignment decision, and file access is a document decision. Each can change without pretending the others changed automatically. The reviewed design supports this composition, but deployed consistency would need observation of edits, reassignment, concurrent updates, and stale portal sessions. A coherent model on paper cannot guarantee those runtime paths remain coherent.", + "A vendor does not need every internal field attached to an RFQ record. Internal notes, operational classifications, or other non-portal values should remain server-side even if the same record powers the external view. Requisia's field visibility boundary lets the package expose a purposeful subset rather than serializing the whole record and hiding parts with presentation code. That reduces the chance that an unstyled response, direct request, or later interface refactor reveals information the visible screen was never meant to carry.", + "Field visibility should also be evaluated against the current assignment and register schema. A field that was appropriate when a package was prepared may no longer be appropriate after policy changes, and an old browser response should not grant future access. The private design gives visibility an explicit role, yet this journal cannot certify every serialization path. Negative tests with hidden fields, direct identifiers, schema changes, cached views, and a different organization's session remain necessary before making a public isolation or security claim." + ] + }, + { + "heading": "Attachments keep their own gate", + "paragraphs": [ + "An attachment may belong to the RFQ context without inheriting the RFQ's entire visibility policy. Some files could be intended for every assigned vendor, while another may be limited, replaced, or revoked independently. Requisia keeps those files as ordinary private documents with document-specific authorization. The package can name that an attachment is available, but the server still evaluates the signed-in recipient and active grant when bytes are requested. A visible package is therefore not a reusable download token.", + "This separation makes revocation and history easier to explain. Removing a document grant does not require deleting the RFQ record or pretending the package never existed; changing the portal assignment does not rewrite the file itself. Notification links can lead back to authentication rather than carrying storage authority. These are intended behaviors observed in local first-party work. Provider access, partial delivery, cache behavior, and revocation timing have not been established publicly and need controlled tests in the target environment." + ] + }, + { + "heading": "Exercise the package as a lifecycle", + "paragraphs": [ + "A credible RFQ test begins with an internal record, selects portal fields, assigns one vendor, attaches two independently governed documents, and confirms that another vendor sees nothing. It then changes a visible value, hides a field, revokes one attachment, reassigns the package, and checks that history remains understandable. The exercise should include direct requests rather than trusting the buttons a portal happens to render, because the server boundary must survive clients that do not follow the interface's intended path.", + "Public evidence can report scenarios and bounded outcomes without revealing supplier names, commercial terms, documents, object locations, or session details. The architectural point already supported locally is that Requisia composes RFQ packages from existing authoritative objects instead of duplicating their truth. Production operation, vendor participation, live notification delivery, and complete protection against disclosure mistakes remain explicit verification responsibilities rather than benefits inferred from that model." + ] + } + ], + "relatedSlugs": [ + "requisia-portal-and-document-assignments", + "requisia-session-derived-authority", + "insuja-formal-requests-and-qa" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "One Login Flow, Several Kinds of Authority", + "slug": "requisia-session-derived-authority", + "excerpt": "Internal operators, administrators, clients, and vendors can enter through one Requisia login surface while each service decision still enforces role, organization, and action scope.", + "status": "published", + "date": "2026-07-12", + "category": "Requisia", + "project": "requisia", + "tags": [ + "Session authority", + "Role separation", + "Organization scope" + ], + "placement": "recent", + "visual": { + "variant": "split-horizon", + "alt": "Animated dither horizon splitting one sign-in path into distinct role and organization decisions" + }, + "body": [ + { + "heading": "A shared doorway is not a shared room", + "paragraphs": [ + "A single login surface can make an enterprise product feel coherent. Internal operators, administrators, clients, and vendors do not need four unrelated authentication brands simply because their work differs. The danger appears when that shared doorway is allowed to imply shared authority. Requisia keeps the entry experience common while treating every protected action as a new question about the signed-in actor, organization, role, resource, and current policy. Authentication begins the decision; it does not finish it.", + "Signed sessions feed separate rules for register edits, workbook operations, portal assignments, private documents, export, deletion, and other sensitive actions in the approved local authorization model. The public summary can name those distinctions without disclosing session formats, provider setup, internal routes, or organization details. That is enough to discuss deliberate separation of authority, but not enough to prove production identity-provider behavior, invitation handling, session expiry, or complete enforcement across deployed services." + ] + }, + { + "heading": "Identity and authority answer different questions", + "paragraphs": [ + "Authentication establishes that a request presents a valid session for an actor. Authorization decides what that actor may do now. The second answer can change while the first remains true: a vendor's package can be withdrawn, a client's document grant can expire, an operator's role can be reduced, or an administrator can leave one organization while retaining access to another. Requisia therefore avoids treating a successful login as a durable ticket to every object that appeared during the session.", + "The distinction also prevents client input from repairing missing authority. Supplying an organization identifier, role name, or recipient value in a request cannot make a revoked session valid for that context. The server reconstructs the relevant scope from trusted state and checks the requested action independently. This is the expected behavior expressed by the local product contract. Public confidence would still require direct-request tests, changed roles during active sessions, cross-organization identifiers, and provider-backed identity evidence rather than interface observation alone." + ] + }, + { + "heading": "Roles are useful only beside resource rules", + "paragraphs": [ + "A broad label such as administrator or vendor cannot capture every procurement decision. An administrator may manage fields but lack permission to perform a destructive purge; a vendor may see one assigned RFQ but not another; a client may view a report without receiving its underlying private workbook. Requisia combines the actor's role with organization and resource scope so a convenient label does not grow into universal authority. The product can then explain a denied action in business terms without revealing unrelated objects.", + "This approach encourages service-specific checks rather than one enormous gate at page entry. Loading a portal dashboard, editing a register record, selecting a Current workbook, and streaming a document each protect different consequences. A screen that was authorized five minutes ago cannot substitute for the check around today's mutation. The reviewed private design follows this layered direction. It remains possible for an unreviewed path or configuration mistake to violate it, which is why production claims require a complete role-and-action inventory plus negative runtime evidence." + ] + }, + { + "heading": "Revocation has to reach an active session", + "paragraphs": [ + "Role and assignment changes matter most after a person has already signed in. If the application only checks authority when the session is created, revocation waits until a logout or distant expiry and becomes operationally weak. Requisia's decision model is designed to evaluate current role and scope at the protected boundary. A session can continue identifying the actor while a document request, register edit, or portal view is denied because the underlying grant changed.", + "The interface should handle that transition without treating it as a mysterious crash. It can explain that access changed, clear stale protected data, and return the person to an appropriate destination, while logs record a bounded reason rather than secrets or customer content. These are product expectations, not witnessed production outcomes. Revocation latency, multiple devices, clock behavior, recovery flows, and provider session semantics must be tested in the intended environment before anyone promises immediate or universal enforcement." + ] + }, + { + "heading": "The proof is a role matrix in motion", + "paragraphs": [ + "A static table of roles is a starting point, but the persuasive test is a sequence. Invite each actor type, sign in, select an organization where appropriate, perform allowed work, attempt adjacent denied actions, change the role or assignment, and retry from the existing session and a direct request. Repeat the journey around records, workbooks, portal objects, private documents, export, and deletion. The evidence should make gaps visible without copying real identities or business data into public artifacts.", + "Invitation, recovery, expiry, revocation, organization switching, and an actor who belongs to more than one context must all appear in the lifecycle. Independent review of deployed identity and application settings belongs beside those journeys. The private local implementation supports separation between a common login experience and the product's different authorities. Live authentication, production authorization, customer access, recovery readiness, and freedom from security defects remain open evidence gates." + ] + } + ], + "relatedSlugs": [ + "requisia-portal-and-document-assignments", + "requisia-private-object-delivery", + "insuja-identity-assurance-separation" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Private Documents Need Authenticated Delivery", + "slug": "requisia-private-object-delivery", + "excerpt": "Requisia keeps private workbooks and documents behind a current server-side authorization decision instead of asking long, difficult-to-guess URLs to behave like access control.", + "status": "published", + "date": "2026-07-11", + "category": "Requisia", + "project": "requisia", + "tags": [ + "Authenticated streaming", + "Private objects", + "Checksum delivery" + ], + "placement": "stories", + "visual": { + "variant": "key-vault", + "alt": "Animated dither vault opening only after session, assignment, version, and object checks align" + }, + "body": [ + { + "heading": "A URL should name a document, not authorize it", + "paragraphs": [ + "Private procurement files often acquire links because links are convenient. The trouble begins when possession of the link is the only thing separating a workbook from the public internet. Links are copied into messages, browser history, support tickets, and analytics; they outlive the assignment that justified them. Requisia treats a browser-visible document or version identifier as a reference. It helps the signed-in person ask for an object, while the server decides whether the current actor and organization may receive the bytes now.", + "Document metadata, version identity, checksums, assignment state, and authenticated delivery remain separate concerns in the approved local design. This account can examine that separation while omitting object locations, provider configuration, routes, credentials, and customer material. It shows why the intended boundary does not rely on obscurity alone; it cannot show that a live storage bucket is private, every production URL is protected, or an external reviewer has assessed the deployed delivery path." + ] + }, + { + "heading": "Integrity and communication return to the same authority", + "paragraphs": [ + "A product record can say which document exists, which version is selected, and which checksum identifies the expected bytes. The object provider stores those bytes, but it should not become the source of business authorization. Requisia resolves the signed-in context, organization, relevant assignment, selected version, and canonical metadata before opening a private stream. That ordering prevents a client from choosing a storage prefix or substituting an unrelated object merely because it discovered a plausible identifier.", + "Checksums add a useful integrity question: are the bytes being delivered the bytes recorded for this version? A mismatch should stop rather than silently return a file that happens to occupy the expected location. Yet a checksum cannot prove who may download the file or whether the content was originally correct; it serves one boundary. The local implementation expresses both metadata and integrity checks. Provider durability, live key policy, upload provenance, and end-to-end content correctness remain outside what this journal can verify.", + "Notification is useful when a client or vendor needs to know that new work is available. It should not freeze the authorization decision into the message. Requisia can send a destination that returns the recipient to the application, where login and the current assignment determine access. If the document is revoked after the email is sent, the old message no longer opens the bytes. This makes revocation a property of the product state instead of a race to retract every copied link.", + "The message also should not reveal private object names or embed credentials that support systems might later capture. Its job is to describe the action in clear language and lead back to authenticated context. The reviewed design maintains this separation between communication and delivery. This article does not claim that production messages are delivered, that unsubscribe or suppression state has been exercised for every recipient, or that every mail client handles links safely. Those are distinct notification and provider verification tasks." + ] + }, + { + "heading": "Failure needs a bounded shape", + "paragraphs": [ + "Private delivery can fail because the assignment changed, the session expired, the version is missing, the object provider is unavailable, the checksum differs, or a stream ends early. Those conditions should not collapse into a fallback that serves another version or a public link. Requisia's design favors a bounded failure that preserves the authoritative record and gives an operator a useful category without exposing object paths, secrets, or another organization's document metadata.", + "Partial streams and retries deserve special care. A retry must repeat the authorization and integrity decisions rather than assuming the first attempt granted permanent access. Operational logs can distinguish requested, authorized, opened, completed, and failed delivery without recording the document itself. These are high-level expectations supported by local contract work. Actual behavior under provider outages, parallel requests, network interruption, and changed permission has not been publicly observed and cannot be inferred from the happy path." + ] + }, + { + "heading": "Test the reference after its authority disappears", + "paragraphs": [ + "The most revealing exercise starts with a valid private download and keeps the reference while everything around it changes. Revoke the assignment, change the recipient, expire the session, select another Current version, remove the object, introduce a safe checksum mismatch, and retry directly. Repeat from a different organization and from an old notification. The expected result is not always the same error message, but no scenario should convert a stale reference into access or leak enough metadata to map private holdings.", + "A complete record should cover large files, parallel downloads, interrupted streams, provider errors, backup restoration, and operator response. Synthetic documents and redacted environmental values can keep that evidence safe for a public project. Current private work supports authenticated delivery around private objects and recorded integrity metadata. Production confidentiality, availability, recovery, and freedom from implementation flaws require the intended deployment and are not established by the local record." + ] + } + ], + "relatedSlugs": [ + "requisia-current-workbook-pointer", + "requisia-portal-and-document-assignments", + "requisia-composite-readiness" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Readiness Is a Composite Signal, Not a Green Build", + "slug": "requisia-composite-readiness", + "excerpt": "Requisia treats frontend compilation as one narrow result inside a larger readiness picture spanning sessions, data, private files, notifications, recovery, and representative journeys.", + "status": "published", + "date": "2026-07-10", + "category": "Requisia", + "project": "requisia", + "tags": [ + "Composite readiness", + "Recovery evidence", + "Journey verification" + ], + "placement": "research", + "visual": { + "variant": "release-bars", + "alt": "Animated dither readiness bars that align only when product, provider, recovery, and journey evidence agree" + }, + "body": [ + { + "heading": "Green describes the check that ran", + "paragraphs": [ + "A successful frontend build is valuable evidence: the source compiled under a known toolchain and produced an artifact. It says nothing by itself about whether sessions work, register data is reachable, private objects are protected, notifications can be sent, or a backup can be restored. Requisia treats readiness as a composite signal because the product crosses all of those boundaries. The release story should preserve each result instead of letting the brightest green check lend confidence to systems it never touched.", + "Source checks, target-environment readiness, provider configuration, representative journeys, backup, restore, rollback, and operator handoff are distinct gates in Requisia's approved readiness record. Their separation is the local observation worth carrying into this entry. Deployment values remain private, and none of the gates is presented as a production pass. A readiness command, checklist, or roadmap cannot substitute for current provider evidence, so the discussion must not be read as a live availability statement." + ] + }, + { + "heading": "Dependencies fail in different ways", + "paragraphs": [ + "The application depends on several kinds of external state. Identity may accept a session while the product data store is unavailable; records may load while a private object cannot be streamed; the product can save a publication event while notification delivery is misconfigured. A useful readiness view checks the required boundary for the selected product mode and returns a non-success result when an essential dependency is absent or invalid. It should not mutate production merely to prove reachability.", + "Optional commercial or communication features also need honest treatment. A mode that does not require a provider should not fail because that provider is absent, while a mode that promises the feature must not mark itself ready using placeholder configuration. The output should name the category of failure without printing secrets or provider identifiers. Requisia's local operating design follows this redacted, fail-closed shape. Whether each external account and target environment currently satisfies it remains independent, drift-prone evidence." + ] + }, + { + "heading": "Readiness is not a restore drill", + "paragraphs": [ + "A health check can confirm that a database responds and that expected migration state appears present. It cannot show that a backup contains the required data, that restoration completes in time, or that the restored application behaves correctly. Requisia keeps backup and restore evidence separate from deployment status for this reason. Recovery is a product capability exercised under controlled failure, not a sentence appended to a successful release command.", + "The same caution applies to private objects and register exports. Being able to generate an export is not proof that all private files can be restored, and a migration process returning success is not proof that rollback thresholds are understood. The local material names these boundaries and asks for explicit records. This journal has not run a production restore, inspected customer backups, or verified provider retention. It therefore cannot turn recovery plans into claims of recoverability." + ] + }, + { + "heading": "A representative journey connects the checks", + "paragraphs": [ + "Even healthy dependencies can compose into a broken product. A representative Requisia journey should authenticate the appropriate actors, create and edit organization-scoped register state, exchange a workbook through preview and apply, select a Current version, assign portal work, deliver a permitted private document, revoke access, export, and exercise the supported recovery boundary. The journey reveals mismatched assumptions between parts that isolated checks report as healthy.", + "Representative does not mean exhaustive or based on real customer content. Synthetic organization data can cover the authority and lifecycle decisions while keeping evidence safe for a public record. Negative steps matter alongside the successful path: a wrong organization, stale preview, revoked file, missing pointer, and failed dependency should remain bounded and intelligible. The reviewed roadmap calls for this kind of evidence, but the existence of the plan does not establish that the entire journey has passed in any live environment." + ] + }, + { + "heading": "Handoff completes the readiness picture", + "paragraphs": [ + "A system is fragile when only its original implementer knows which warning can be ignored, where recovery begins, or which optional mode is active. A credible handoff names the artifact, environment, evidence dates, unresolved risks, rollback thresholds, recovery responsibilities, and owners for manual gates. Someone else should be able to repeat the readiness checks and explain the result without private oral context. That standard makes uncertainty visible rather than converting familiarity into an unreviewed production assumption.", + "Requisia needs an aligned set of current, redacted results rather than one larger green badge: release checks, target dependency readiness, a representative procurement journey, negative authorization cases, a backup-and-restore exercise, a rollback decision, and operator handoff. The private local work currently supports only the idea that readiness is composite evidence. Deployment, production readiness, customer operation, security closure, and successful disaster recovery remain unproven until their own records exist." + ] + } + ], + "relatedSlugs": [ + "requisia-preview-before-apply", + "requisia-private-object-delivery", + "gy-qualification-before-release" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Tenant Boundaries as Types, Not Repeated Strings", + "slug": "insuja-typed-tenant-boundaries", + "excerpt": "Insuja treats tenant scope as a value the application must establish before business work begins, replacing scattered organization strings with one explicit and reviewable boundary.", + "status": "published", + "date": "2026-07-09", + "category": "Insuja", + "project": "insuja", + "tags": [ + "Tenant scope types", + "Boundary resolution", + "Cross-tenant denial" + ], + "placement": "build-business", + "visual": { + "variant": "context-rings", + "alt": "Animated dither rings holding separate tenant contexts without allowing their edges to overlap" + }, + "body": [ + { + "heading": "Scope should not be a loose convention", + "paragraphs": [ + "A multi-tenant product can look well separated while every request still passes an organization name through several layers as ordinary text. That pattern asks each reader, helper, and background task to remember what the text means and where it came from. One missed comparison can turn a valid record reference into a cross-tenant read. Insuja's design instead treats tenant scope as a distinct value that must be established before deal data can be requested, changed, searched, or shared.", + "Trusted scope is distinct from user-supplied references in the approved local design, and tenant context is expected to accompany later decisions. That makes the boundary a product constraint rather than a label added for documentation. The observation can support a public account of intent and structure, but it cannot prove that a production deployment, an external identity provider, or every live data operation currently applies the constraint without exception." + ] + }, + { + "heading": "Resolve scope before granting capability", + "paragraphs": [ + "A request may arrive with a session, a workspace selection, and a reference to a deal, yet those inputs do not deserve equal authority. The system should resolve the signed-in actor and their available tenant memberships from trusted state, select a valid context, and only then look up a tenant-owned resource. Repeating that resolution inside every feature invites drift. Establishing it once gives the rest of the operation a narrower vocabulary: it can receive scoped capabilities instead of rebuilding trust from strings.", + "This ordering also makes missing context safe. If membership cannot be established, the operation stops before it asks whether a referenced object exists. There is no universal fallback tenant and no helpful guess based on the last page someone visited. The interface can ask the person to choose an available workspace again, but it should not convert ambiguity into access. A typed boundary is valuable because an unresolved state remains visibly incomplete rather than becoming an empty string that later code may accept.", + "Tenant membership is necessary, but it is not the same as authority to perform every action inside that tenant. A useful scoped value can carry or lead to the permitted operation: view a shared release, answer a formal request, manage seller disclosure, or work inside a buyer-private space. Features then ask for the capability they actually require. That is easier to review than a generic tenant identifier passed into code that silently decides whether the caller is an administrator, participant, or observer.", + "The distinction becomes especially important when a person belongs to more than one tenant or changes roles during an active session. A resource reference from one workspace must not become meaningful after the interface switches to another, and a previously opened screen must not preserve authority after membership changes. Insuja's local design points toward fresh server-side decisions at meaningful boundaries. The journal cannot establish whether all caches, long-lived views, or asynchronous work have been exercised under those transitions in a deployed environment." + ] + }, + { + "heading": "Failure should remain inside the boundary", + "paragraphs": [ + "A denial can leak data even when it returns no record. Different messages for nonexistent, inaccessible, and differently owned objects allow repeated guesses to reveal which references are real. Tenant-safe behavior therefore keeps outward responses deliberately modest while retaining enough private diagnostic context for authorized operators. Search results, counts, activity summaries, and notification previews deserve the same treatment; a perfectly protected detail page does not help if a sidebar already disclosed another tenant's title.", + "Background work needs equal discipline. A queued task should carry a bounded purpose and re-establish the authority needed for its action rather than relying on ambient global state. Retries should not drift into a different tenant because a default changed, and logs should describe outcomes without copying sensitive deal content. These are architectural expectations observed in first-party planning and focused local behavior, not claims that a live queue, monitoring system, or operational response has passed production review." + ] + }, + { + "heading": "Proof requires adversarial journeys", + "paragraphs": [ + "The strongest test is not a successful read in the expected workspace. It is a matrix of negative journeys: reuse a reference after switching tenants, remove membership while a page is open, retry a stale action, search for a known title from the wrong side, and inspect whether totals or timing expose anything. The same matrix should cover direct navigation, bulk operations, background completion, and notification rendering. Each refusal should be stable, comprehensible, and free of information about the protected resource.", + "Those adversarial journeys define the remaining evidence gap. The available private record supports tenant context as an explicit local boundary with later permissions composed inside it. Repeatable tests against the intended deployment, representative role changes, external-service evidence, and independent review are still required. A type-shaped scope makes unsafe states harder to express and easier to review; it is not a certificate of deployed isolation." + ] + } + ], + "relatedSlugs": [ + "insuja-identity-assurance-separation", + "insuja-revocable-permission-proofs", + "insuja-permission-safe-search-feed" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Login Assurance Is Not Data Permission", + "slug": "insuja-identity-assurance-separation", + "excerpt": "Insuja separates confidence in a signed-in actor from permission to see a particular deal object, so a strong login never becomes a universal data pass.", + "status": "published", + "date": "2026-07-08", + "category": "Insuja", + "project": "insuja", + "tags": [ + "Identity assurance", + "Resource authorization", + "Session transitions" + ], + "placement": "recent", + "visual": { + "variant": "key-vault", + "alt": "Animated dither key approaching several vaults while only one resource-specific door opens" + }, + "body": [ + { + "heading": "Authentication answers one question", + "paragraphs": [ + "A successful login can establish that the current session belongs to a known actor with an acceptable level of assurance. It cannot establish that the actor may read every opportunity, attachment, message, or workspace the application can address. Collapsing those questions feels efficient because both are called access, but it gives identity evidence a power it does not contain. Insuja's design keeps authentication as the start of a decision and evaluates data permission against the requested resource and action afterward.", + "Three decisions appear separately in the approved local product boundary: identity establishes the actor, tenant context establishes the relevant organization, and policy determines what the actor may do. Their separation is credible evidence of intended design and focused implementation behavior. It supplies no public proof for production identity settings, provider operation, account recovery, or complete authorization coverage across a deployed service." + ] + }, + { + "heading": "Assurance belongs to the session", + "paragraphs": [ + "Identity assurance has its own lifecycle. A session can be fresh or old, a sign-in method can provide different confidence, and a sensitive action can reasonably require a recent confirmation. Those properties describe how much confidence the service has in the actor at this moment. They should shape session renewal and step-up prompts without being mistaken for ownership of a deal. A recently verified buyer still cannot open seller-private material that was never released to that buyer.", + "The reverse is also important. A person may have a legitimate resource permission while their session is no longer strong enough to exercise it safely. The correct response is to renew identity assurance and then reevaluate the resource decision, not to cache the earlier answer indefinitely. This composition produces understandable states: sign in, confirm again, choose a valid tenant, or request access. Each state corresponds to a missing condition instead of presenting one vague denial that encourages unsafe shortcuts." + ] + }, + { + "heading": "Permission belongs to the resource", + "paragraphs": [ + "A deal object has relationships that a login token cannot know by itself: which tenant owns it, whether the actor participates, whether a seller released a specific item, whether a buyer-private note is involved, and which action is requested. Authorization should evaluate those facts using authoritative current state. Passing only an actor role such as buyer or seller is too coarse. Roles help describe possible responsibilities, but the resource relationship determines whether a concrete read or mutation is allowed.", + "This boundary prevents broad interfaces from becoming accidental policy. A navigation link, a hidden button, or a filtered list may improve usability, yet none can grant authority. Direct requests must receive the same server-side resource evaluation even when the interface never offered the action. The locally reviewed design follows that principle at its declared boundaries. Production confidence would still need route inventories, negative tests, role-change exercises, and evidence that alternate clients cannot bypass the same policy decision." + ] + }, + { + "heading": "Denial should be ordinary and legible", + "paragraphs": [ + "When authentication and permission are separate, the product can explain failure without exposing protected facts. An expired session can invite reauthentication. A missing tenant membership can invite a workspace change. A resource denial can remain intentionally neutral about whether the referenced deal exists. The interface should preserve safe work where possible, avoid loops between sign-in and denial screens, and never ask the person to solve an authorization problem by repeatedly supplying private references.", + "Audit events need the same separation. Recording that an authenticated actor attempted a denied action can support review, but the record should minimize copied deal content and should not turn routine denials into noisy security theatre. Operational detail belongs in protected evidence with bounded retention and access. The public journal can describe those design expectations, while actual monitoring coverage, retention policy, and response practice remain deployment questions that cannot be inferred from local application behavior." + ] + }, + { + "heading": "Test the composition, not the labels", + "paragraphs": [ + "A useful verification matrix changes one condition at a time. Keep the same actor and change the tenant; keep the tenant and change the deal relationship; revoke a release while retaining the session; age the session while retaining permission; then repeat through direct navigation, search, downloads, and background work. Success means each layer contributes only its intended authority. A strong identity should never expand the resource set, and a valid resource relationship should never excuse inadequate session assurance.", + "The matrix also defines the evidence limit. Insuja's private local work deliberately separates identity assurance from data permission and exposes that distinction in the design. Separating the questions makes reviews and failures more precise, but live identity-provider behavior, real organizations, recovery flows, and every delivery channel need environment-level verification. Deployed assurance begins with that matrix and independent adversarial testing, not with the architectural separation alone." + ] + } + ], + "relatedSlugs": [ + "insuja-typed-tenant-boundaries", + "insuja-revocable-permission-proofs", + "insuja-seller-controlled-releases" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Revocable Permission Proofs for Sensitive Deal Data", + "slug": "insuja-revocable-permission-proofs", + "excerpt": "Insuja models permission to sensitive deal data as bounded, purpose-specific proof that can expire or be revoked without pretending a past grant lasts forever.", + "status": "published", + "date": "2026-07-07", + "category": "Insuja", + "project": "insuja", + "tags": [ + "Permission proofs", + "Revocation semantics", + "Purpose limitation" + ], + "placement": "stories", + "visual": { + "variant": "signal-window", + "alt": "Animated dither signal passing through a narrow permission window that can close immediately" + }, + "body": [ + { + "heading": "A grant should be a bounded fact", + "paragraphs": [ + "Sensitive deal work often needs more precision than a permanent member list. A seller may allow one buyer to view one released item for a defined purpose while keeping drafts, internal notes, and later versions private. Representing that decision as a generic can-view flag loses the subject, object, action, and lifecycle that made the grant reasonable. Insuja's design treats permission as proof of a specific relationship, so later reads can ask what was granted instead of assuming participation means universal visibility.", + "Permission is evaluated beside tenant, resource, actor, and requested action in Insuja's approved local model. That relationship supplies the architectural basis for this discussion while leaving the implementation evidence private. It cannot establish a production authorization service, live revocation latency, external delivery controls, or the absence of undiscovered bypasses. The principle can be stated without private identifiers, operational settings, or real deal data." + ] + }, + { + "heading": "Expiry and revocation bound the proof", + "paragraphs": [ + "A useful permission proof answers enough questions to prevent reuse outside its meaning. It identifies the protected class of resource, the actor or bounded audience, the allowed operation, the tenant context, and the condition under which the decision stops applying. Some grants may end at a stated time; others may remain valid until the seller withdraws a release or a participant leaves the deal. The system should evaluate that context rather than converting proof into an unqualified session-wide privilege.", + "Expiry is not merely cleanup. It makes uncertainty fail closed when a relationship was intentionally temporary. The interface can show that access ended and offer a safe way to request a new decision, but it cannot extend the old grant for convenience. Likewise, a copied link should carry no independent authority. Opening it should lead to a current server-side evaluation, ensuring that the same address can become unavailable when the underlying permission no longer holds.", + "Revocation is credible only if the product knows which derived surfaces might still expose the data. Detail views are the obvious case, but search entries, recent-item lists, previews, notifications, generated exports, and queued work can preserve fragments after the main screen denies access. Insuja's model therefore treats withdrawal as a change that downstream readers must respect, not as a visual toggle. Caches and materialized views need bounded freshness or explicit invalidation so convenience does not silently defeat the seller's decision.", + "A completed external disclosure cannot always be recalled from another person's memory or device, and the product should not promise that fiction. Revocation can stop future service-mediated reads, remove current discovery, and prevent new deliveries within the system's boundary. Clear language about that limit is safer than claiming data has vanished everywhere. The locally observed design supports prospective control; proving actual withdrawal across deployed stores and delivery providers requires environment evidence that this article does not possess." + ] + }, + { + "heading": "Least disclosure shapes every response", + "paragraphs": [ + "Permission proofs should authorize only the response needed for the action. A list may reveal a safe label without including a confidential body; a notification may indicate that something changed without copying the protected content; a count may need to exclude inaccessible objects entirely. This discipline reduces the number of places revocation must chase and limits the consequence of a rendering mistake. It also makes policy review concrete because each surface declares what information it intends to disclose.", + "Denials deserve similar restraint. A failed request should not reveal whether another tenant owns the reference, whether a newer private version exists, or which seller action would unlock it. Protected diagnostic evidence can record the evaluated reason for authorized review without echoing the deal itself into routine logs. These requirements appear in first-party design reasoning, but actual observability, retention, and support practices remain private operational concerns whose production quality cannot be certified from a local implementation review." + ] + }, + { + "heading": "Verification follows the revocation graph", + "paragraphs": [ + "The right test begins with a legitimate release, observes every permitted surface, revokes the grant, and revisits each surface through both an existing session and a fresh one. It should repeat while a search index is behind, a notification is queued, an export is being prepared, and a browser holds an old page. The goal is not only a denied detail request; it is consistent disappearance or neutralization of every service-controlled derivative without exposing why an unrelated actor was denied.", + "The available private evidence represents sensitive permission as contextual and revocable rather than permanent ambient access. That structure creates a place to express withdrawal and purpose. Measured propagation, failure injection, representative provider behavior, and independent review must then follow the revocation graph in the intended deployment. Operational assurance starts only when every consumer is shown to honor the change." + ] + } + ], + "relatedSlugs": [ + "insuja-typed-tenant-boundaries", + "insuja-identity-assurance-separation", + "insuja-seller-controlled-releases" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Seller Releases as Explicit Controlled Disclosure", + "slug": "insuja-seller-controlled-releases", + "excerpt": "Insuja treats seller disclosure as an explicit release event, preserving the line between private preparation and the exact deal material a chosen buyer may receive.", + "status": "published", + "date": "2026-07-06", + "category": "Insuja", + "project": "insuja", + "tags": [ + "Seller disclosure", + "Release boundaries", + "Audience control" + ], + "placement": "research", + "visual": { + "variant": "split-horizon", + "alt": "Animated dither horizon separating seller-private material from a narrow illuminated release channel" + }, + "body": [ + { + "heading": "Sharing should be a deliberate state change", + "paragraphs": [ + "A seller workspace can contain drafts, working notes, candidate files, and internal decisions long before any buyer should see them. If visibility is inferred from where an item sits or whether someone copied a link, private preparation can become disclosure by accident. Insuja instead frames a seller release as an explicit state change. Material remains seller-private until an authorized seller action identifies what is being released, to whom it is being released, and which shared workflow may present it.", + "Seller-controlled state and buyer-visible shared state remain distinct in the approved local model, and release is treated as a meaningful action rather than a display preference. That focused observation is enough to explain why disclosure needs its own state transition. The underlying implementation remains private, so the entry cannot verify a production tenant, report a real seller completing a release, or demonstrate that every deployed delivery surface enforces the boundary without exception." + ] + }, + { + "heading": "Name the subject, audience, and purpose", + "paragraphs": [ + "A useful disclosure decision names a stable subject. Depending on the workflow, that might be a selected document version, a bounded set of answered fields, or a prepared response to a formal request. A vague instruction to share the deal is too broad because a deal continues to change. The seller should be able to review the exact material and audience represented by the action, while the system records enough context to distinguish the released snapshot from later private edits.", + "Consider a hypothetical financial summary that a seller prepares over several revisions. Releasing the reviewed revision to one buyer should not expose the next internal draft, and correcting that draft should not silently rewrite what the buyer previously received. The interface can present the new revision as another release decision. This makes the handoff understandable to both sides and prevents ordinary editing from acquiring the authority of publication merely because the content has a familiar title.", + "A buyer's participation in one opportunity does not make every seller release visible, and a release to one buyer does not establish a general catalogue. The decision should remain scoped to the intended tenant relationship, recipient group, resource, and action. Shared request or Q&A state may reveal that a response exists while the released payload follows its narrower permission. That distinction lets the workflow remain legible without turning a status update into a substitute for content authorization.", + "The same rule applies outside the main detail view. Search results, activity summaries, notifications, exports, and recent-item lists must derive their visible fields from the current release boundary. A notification can say that a response is available and lead the recipient back through a fresh permission decision; it need not copy sensitive text into an email. The local design points toward this least-disclosure approach, but live provider behavior and end-to-end production delivery remain unverified by this article." + ] + }, + { + "heading": "Correction and withdrawal do not erase history", + "paragraphs": [ + "Sellers need a way to correct or withdraw material, yet the product should describe honestly what those actions mean. A new release can supersede an earlier one for future service-mediated access, and a withdrawal can stop later reads when policy allows. Neither action can guarantee that a recipient forgets information already viewed or that an independently saved copy disappears. Precise language preserves trust by promising control over the system's current surfaces instead of imaginary control over another person's memory.", + "An accountable history should therefore record that a release, replacement, or withdrawal occurred without placing the sensitive payload into a broadly readable log. The record can support questions about who acted, what bounded subject changed, which audience was intended, and when the decision took effect. Those are high-level expectations from first-party work, not evidence of a complete operational audit system. Retention, recovery, support access, and review procedures still require separate deployment evidence and policy approval." + ] + }, + { + "heading": "Prove the handoff from both sides", + "paragraphs": [ + "A representative verification journey should begin with seller-private material and confirm that the buyer cannot discover it through direct navigation, search, counts, or notifications. The seller then releases a reviewed subject to one buyer, after which that buyer can find and read only the intended material while another buyer still sees nothing. The journey should continue through a correction, a withdrawal, a stale browser view, and an old link, checking the seller and buyer experiences at every transition.", + "The private record supports explicit seller disclosure separated from private preparation. Organization bootstrap, external identity, provider delivery, propagation timing, recovery, and independent adversarial review remain outside it. An explicit release makes the decision reviewable; operational assurance requires following that release through every downstream surface. The durable question after release, replacement, or withdrawal is who can see which bounded subject now." + ] + } + ], + "relatedSlugs": [ + "insuja-revocable-permission-proofs", + "insuja-buyer-command-workspaces", + "insuja-formal-requests-and-qa" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Buyer Workspaces Without Seller Data Leakage", + "slug": "insuja-buyer-command-workspaces", + "excerpt": "Insuja gives buyer teams a private command workspace for their own diligence while keeping seller material governed by explicit releases and current permission.", + "status": "published", + "date": "2026-07-05", + "category": "Insuja", + "project": "insuja", + "tags": [ + "Buyer-private work", + "Data separation", + "Controlled references" + ], + "placement": "build-business", + "visual": { + "variant": "workspace-beacon", + "alt": "Animated dither workspaces with a buyer beacon illuminating only explicitly released seller material" + }, + "body": [ + { + "heading": "A buyer needs room to think privately", + "paragraphs": [ + "A diligence team produces its own sensitive material: screening notes, internal questions, review assignments, tentative interpretations, and decisions about what to investigate next. That work should not appear in the seller's workspace merely because both parties participate in the same opportunity. Insuja treats the buyer command workspace as a separate ownership boundary. Shared deal activity can connect the parties, while buyer-private analysis remains visible only to the buyer tenant and the people currently authorized within it.", + "Seller, buyer, and shared workflow boundaries occupy separate parts of Insuja's approved local product model. The distinction supports one public observation: buyer work is not simply another view of seller state. It records design intent and focused implementation direction without proving production isolation, real participant onboarding, external identity behavior, or complete deployed authorization coverage. Explaining that ownership boundary requires no actual deal, tenant, or operational identifier." + ] + }, + { + "heading": "Shared references should not become copied authority", + "paragraphs": [ + "A buyer workspace may need to point to material the seller released, but copying the seller payload into every buyer record creates a second disclosure system that can outlive withdrawal. A safer model keeps the buyer's annotation and workflow state separate from the governed seller resource. The reference helps the interface locate the subject, while a current permission decision determines whether the seller content can still be rendered. Losing access can leave the buyer's own note intact without preserving protected seller text inside it.", + "Imagine a reviewer writing, ‘Revisit the margin assumptions,’ beside a released summary. That buyer-authored instruction can remain useful if the seller later withdraws the summary, but the screen should no longer reproduce the unavailable figures. If the product permits a durable buyer snapshot, that must be an explicit, policy-visible capability rather than an accidental consequence of caching. The distinction makes data handling explainable and gives both parties a clearer account of what the system actually controls." + ] + }, + { + "heading": "Collaboration remains tenant-scoped", + "paragraphs": [ + "Buyer teammates need assignments, status, comments, and search across their own diligence work. Each of those conveniences must begin with buyer-tenant scope and current membership. A person invited to a different opportunity should not inherit unrelated notes simply because their account already exists, and someone removed from the buyer team should not retain access through an old tab or remembered reference. Navigation and hidden controls support usability, but server-side resource decisions remain the authority for every direct request.", + "The same scope applies to derived surfaces. Activity counts should not reveal another buyer team's workload; search should not index seller-private titles that were never released; notification previews should avoid copying protected content; and exports should contain only the buyer-owned and currently permitted fields declared by their purpose. These are local first-party design expectations. Actual background processing, cache expiry, email behavior, and export delivery in an intended deployment remain evidence gates rather than conclusions that can be drawn from this journal." + ] + }, + { + "heading": "Derived conclusions need visible provenance", + "paragraphs": [ + "Buyer analysis often combines observations from several released items with the team's own judgment. The interface should distinguish those layers so a reader can tell whether a statement is seller-provided, buyer-authored, or a hypothetical conclusion under review. Provenance also helps when a source release changes: the team can identify which notes need reconsideration without letting a changed seller document silently rewrite the buyer's history. Clear attribution is a product aid, not a claim that the system can determine whether a human conclusion is correct.", + "Deletion and retention deserve equally explicit language. Removing a buyer note can follow the buyer tenant's policy, while withdrawing seller access follows the seller's release decision; neither should cascade into the other's authoritative state by accident. Any retained audit facts should minimize payload content and remain protected. The reviewed private work establishes the conceptual separation, but public evidence would still need approved retention rules, recovery exercises, representative user review, and confirmation that provider-level copies follow the intended lifecycle." + ] + }, + { + "heading": "Test with two buyers and one changing release", + "paragraphs": [ + "A useful verification journey gives two independent buyer tenants access to different releases from the same hypothetical seller. Each team creates private notes, assignments, searches, and notifications. The test then changes one seller release, removes one buyer member, withdraws another item, and attempts direct access with stale references. Success means each buyer retains only its own work, currently authorized seller material appears only where intended, and shared workflow status never smuggles the protected payload across a boundary.", + "The private evidence supports a buyer command workspace as its own tenant-scoped domain with seller disclosure under separate authority. Live organization bootstrap, deployed behavior, recovery, provider isolation, and independent security review are not part of that record. Separating ownership from reference makes leakage paths easier to reason about. A one-seller, two-buyer exercise with a changing release is the end-to-end evidence still needed from the environment that will operate the product." + ] + } + ], + "relatedSlugs": [ + "insuja-seller-controlled-releases", + "insuja-formal-requests-and-qa", + "insuja-permission-safe-search-feed" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Formal Requests and Q&A as Shared Workflow State", + "slug": "insuja-formal-requests-and-qa", + "excerpt": "Insuja turns diligence requests and Q&A into explicit shared workflow state, while keeping each party's private preparation outside the shared record.", + "status": "published", + "date": "2026-07-04", + "category": "Insuja", + "project": "insuja", + "tags": [ + "Formal requests", + "Shared Q&A", + "Workflow provenance" + ], + "placement": "recent", + "visual": { + "variant": "shared-notebook", + "alt": "Animated dither notebook joining a bounded buyer question to a deliberately released seller response" + }, + "body": [ + { + "heading": "A request is more than a message", + "paragraphs": [ + "Diligence can disappear into an inbox when a question, its intended subject, the responsible party, and the accepted answer live in separate messages. Forwarding the thread creates copies without creating shared understanding. Insuja treats a formal request as a first-class workflow object: a bounded question or evidence need that the permitted buyer and seller participants can locate, follow, and move through an explicit lifecycle. Conversation can support the work, but it does not replace the state that says what remains unresolved.", + "Shared request and Q&A activity sit apart from seller-private and buyer-private preparation in the approved local workflow. The boundary is visible enough to discuss without publishing operational identities, deal facts, or provider details. It says nothing about real parties using the workflow in production, live notifications arriving, or every deployed route and search surface preserving the separation." + ] + }, + { + "heading": "A small lifecycle creates shared meaning", + "paragraphs": [ + "A request can be newly raised, under review, clarified, answered, or closed without pretending that every workflow needs the same labels. What matters is that transitions have clear actors and preconditions. A buyer can identify an evidence gap, a seller can ask what would satisfy it, and the parties can recognize when a response was formally released. The current state then answers an ordinary question that message history handles poorly: what action is expected now, and from whom?", + "Transitions should not rewrite the record that preceded them. A clarification can narrow the question while preserving why it changed; a replacement answer can supersede an earlier response without making the earlier handoff unknowable; reopening can record that new evidence changed the assessment. This history needs useful timestamps and actors but should avoid copying the full sensitive payload into a broadly readable activity stream. The design makes accountability possible while keeping content access governed by its own permission." + ] + }, + { + "heading": "Shared state still has an audience", + "paragraphs": [ + "Calling a workflow shared does not make it public to every participant or every tenant. Each request belongs to a bounded deal context and an intended audience. A buyer's internal draft question can remain buyer-private until it is formally submitted, and a seller's working answer can remain seller-private until it is deliberately released. Once shared, the request state can coordinate the named parties without exposing their private notes, unrelated requests, or material from another opportunity.", + "Permissions must be evaluated on direct reads and changes, not inferred from whether a card appeared on a dashboard. Search, counts, activity summaries, and notifications should expose only the safe fields allowed for the current participant. A notification can identify that action is needed and lead to the authenticated workflow without embedding the answer itself. Those are first-party local design expectations; production provider behavior, recipient mapping, and delivery behavior remain separate verification gates." + ] + }, + { + "heading": "Evidence is released, not attached by accident", + "paragraphs": [ + "An answer may refer to seller-controlled material, but mentioning a document does not automatically grant the buyer its bytes. The formal response should identify the bounded evidence subject, while current release and permission decisions govern delivery. That separation keeps workflow state understandable after a document is withdrawn or superseded. It also prevents a convenient attachment field from bypassing the seller's explicit disclosure boundary simply because both objects appear in the same screen.", + "A hypothetical buyer might ask for an updated operating summary. The seller can prepare several private drafts, release one reviewed version as the answer, and later issue a correction. The request history can show that an answer changed, while the buyer sees only versions actually released to that buyer. If access is withdrawn, the service can stop future delivery without falsely promising to erase information already viewed. Clear state and honest limits make the handoff more trustworthy than an opaque file exchange." + ] + }, + { + "heading": "Verification must cross the private and shared edges", + "paragraphs": [ + "A representative test should create a buyer-private draft, submit it as a formal request, prepare a seller-private answer, release a bounded response, clarify the request, replace the answer, and close the workflow. At each step, another buyer, an unrelated seller participant, a removed member, and a stale session should fail to discover protected content through direct navigation, search, notifications, or counts. Old links should resolve against current permission rather than preserving yesterday's authority.", + "Insuja's private local record models requests and Q&A as explicit shared workflow state between otherwise separate workspaces. Formal state makes responsibility and provenance legible, but the missing proof is a transition-by-transition run across seller-private, buyer-private, and shared state, including search and notification effects. Production readiness, real-user adoption, deployed isolation, recovery, and independent review all depend on exercising that lifecycle in the intended environment." + ] + } + ], + "relatedSlugs": [ + "insuja-seller-controlled-releases", + "insuja-buyer-command-workspaces", + "insuja-permission-safe-search-feed" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Permission-Safe Search Starts With Reconciliation", + "slug": "insuja-permission-safe-search-feed", + "excerpt": "Insuja treats search as a derived permission-bearing view that must reconcile with authoritative deal state, including releases, revocations, and deletion.", + "status": "published", + "date": "2026-07-03", + "category": "Insuja", + "project": "insuja", + "tags": [ + "Search reconciliation", + "Permission-aware discovery", + "Revocation propagation" + ], + "placement": "stories", + "visual": { + "variant": "event-river", + "alt": "Animated dither event river flowing through a reconciliation grid that removes stale search entries" + }, + "body": [ + { + "heading": "Search is another disclosure surface", + "paragraphs": [ + "A search result can reveal sensitive information before anyone opens its destination. A title, snippet, count, owner label, or timing hint may confirm that a private deal object exists. Insuja therefore treats discovery as part of authorization rather than a neutral convenience layered over protected detail pages. The visible result set must begin with the signed-in actor, tenant context, current deal relationships, and explicit releases, then include only fields suitable for that particular search surface.", + "Permission-aware discovery and reconciliation are deliberate concerns in Insuja's approved local design, especially when shared state changes or disappears. They provide a bounded basis for examining search behavior without revealing a query, customer term, internal service name, or infrastructure topology. The observation does not establish a production index, live feed, measured propagation time, complete deletion, or external provider behavior." + ] + }, + { + "heading": "Query-time filtering is necessary but incomplete", + "paragraphs": [ + "Filtering results for the current actor is a crucial final check, yet it cannot repair every unsafe index. A stale document may contain a snippet that should never have been copied, and aggregate counts or suggestions can reveal it even when the main hit is filtered. Indexing should therefore minimize fields, preserve the tenant and resource boundary needed for evaluation, and avoid importing seller-private or buyer-private text unless that search experience has a clear authorized purpose.", + "The product should also resist a common shortcut: trusting a stored audience list forever. Membership changes, releases are withdrawn, questions move between private and shared states, and whole resources can be deleted. Search must evaluate current authority or consume bounded permission state whose freshness is explicit. An old browser view should not make a stale hit usable; opening a result still requires a fresh server-side resource decision. Discovery helps a person navigate, but it never becomes the capability to read." + ] + }, + { + "heading": "Lifecycle updates need reconciliation", + "paragraphs": [ + "Creating or releasing a resource may add a discoverable representation. Editing may change its safe title or summary. Revocation should remove it from audiences that no longer qualify, and deletion should remove both the result and any derivative suggestion the product controls. These consequences can arrive asynchronously, so the design needs to acknowledge lag rather than assuming one successful update means every view now agrees. During uncertainty, the safer experience is omission or a neutral unavailable state, not disclosure from a stale copy.", + "Failure is especially visible around retries. The same change may be observed more than once, arrive after a newer change, or be interrupted midway. Applying updates idempotently and comparing their logical order prevents an old release from resurrecting after a withdrawal. Those are general properties of the focused first-party design, not claims about a particular queue or index product. Proving them in operation would require controlled reordering, duplication, interruption, and recovery exercises in the intended environment.", + "Incremental updates make search timely, but no delivery path should be treated as infallible. Reconciliation compares the authoritative set a tenant and permission state should expose with the derived set search currently holds. It can add a missed item, refresh a changed safe representation, and remove an orphan whose source was deleted or whose audience lost permission. The comparison turns silent drift into observable work and provides a recovery path after interruption without requiring operators to guess which individual update vanished.", + "A sound reconciliation pass remains bounded. It should operate within one established tenant and purpose, avoid reading unrelated private payloads merely to calculate presence, and record counts or outcomes without copying sensitive content into logs. Repeated runs should converge on the same result, including deletion, rather than generating duplicates or restoring stale entries. The local design supports this repair model. Production scale, scheduling, provider limits, alerting, and operator response are external facts that this article neither observes nor certifies." + ] + }, + { + "heading": "Test discovery after permission turns backward", + "paragraphs": [ + "The revealing test is not whether a newly released item appears. It is whether a once-visible item disappears everywhere it should after access contracts. A representative matrix should withdraw a seller release, remove a buyer member, return a shared question to a private draft when policy allows, and delete a resource. It should then inspect exact search, prefixes, suggestions, counts, recent items, direct links, stale sessions, duplicated updates, skipped updates, and a later reconciliation pass.", + "Private evidence supports search as a permission-bearing derived view and reconciliation as a first-class response to drift. Production isolation, deletion guarantees, propagation targets, provider resilience, and independent adversarial review remain outside that observation. Query checks protect the present request; a demonstrated reconciliation run is what would show the derived history can recover after diverging from authoritative state." + ] + } + ], + "relatedSlugs": [ + "insuja-typed-tenant-boundaries", + "insuja-revocable-permission-proofs", + "insuja-formal-requests-and-qa" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Repository Access Should Begin With an Explicit Yes", + "slug": "hyoka-opt-in-repository-access", + "excerpt": "A local assistant should enter a repository only after a person chooses that scope, can see what was granted, and can withdraw it without confusing project access with broader machine authority.", + "status": "published", + "date": "2026-07-02", + "category": "Hyoka Hanesu", + "project": "hyoka-hanesu", + "tags": [ + "Repository consent", + "Visible scope", + "Local tools" + ], + "placement": "research", + "visual": { + "variant": "local-orbit", + "alt": "Animated dither orbit closing around a deliberately selected repository boundary" + }, + "body": [ + { + "heading": "Opening a project should be a consent event", + "paragraphs": [ + "A repository assistant is most useful when it can read enough of a project to answer concrete questions, yet that usefulness does not justify ambient reach across a machine. The first meaningful action should be a person selecting the project they intend to discuss. That moment establishes a visible boundary between the chosen material and everything else nearby. Hyoka Hanesu treats this as part of the product conversation: access begins with a deliberate yes, not with a scan that asks forgiveness after private material has already entered the session.", + "An explicitly chosen project organizes the approved local workflow, joining consent and scope at the start of a session. That design observation can be shared without repository contents, machine locations, credentials, or provider settings. It cannot demonstrate operating-system containment, protection from every possible tool misuse, or a distributed build behaving identically on another machine. Those environment questions remain private and open, and the limit matters as much as the design idea." + ] + }, + { + "heading": "The granted scope must stay legible", + "paragraphs": [ + "A file picker alone is not a durable explanation of authority. Once a project is open, the interface should continue to identify the selected scope in human language and make project changes conspicuous. A stale title, remembered conversation, or recent-project shortcut must not leave someone wondering which material the assistant can currently inspect. Legibility also improves error handling: when a request depends on content outside the selected boundary, the product can explain that limitation instead of quietly widening its search or returning a mysterious partial answer.", + "The safest default for missing or invalid scope is to stop project work while preserving enough interface state to let the person choose again. That failure should not fall back to a broader directory, an earlier project, or an implicit development location. This is a design rule recorded from local first-party work, not proof that every indirect reference, linked resource, or platform-specific edge case has been contained. Boundary-escape exercises and representative packaging tests would still be required before making a stronger public security statement." + ] + }, + { + "heading": "Project consent is not blanket tool consent", + "paragraphs": [ + "Choosing a repository answers where the assistant may gather project context; it does not automatically answer what every tool may do. Reading a selected file, proposing a patch, changing a file, starting a process, or contacting a remote service carry different consequences. A predictable assistant makes those differences visible and places additional confirmation around actions that create side effects. The repository boundary should constrain each operation, while the operation itself remains subject to its own explanation and approval when the consequence deserves one.", + "This separation prevents a convenient phrase such as ‘open this project’ from becoming an invisible grant for unrelated machine activity. It also gives the person a useful mental model: project selection bounds context, tool policy bounds actions, and backend choice bounds where processing occurs. The reviewed design direction supports that layered model locally. It does not establish that hostile instructions cannot manipulate a tool, that every platform API honors the intended boundary, or that a production-grade sandbox has been independently assessed." + ] + }, + { + "heading": "Consent needs a lifecycle, not a checkbox", + "paragraphs": [ + "A useful grant can outlive the screen where it was made, so persistence must be deliberate. Reopening a recent project may be helpful, but the interface should distinguish remembered selection from an active session and provide a clear way to close or replace it. Changing projects should invalidate assumptions tied to the earlier context, including cached excerpts and pending actions. Otherwise a conversation can display one project while an old tool request still points at another, turning a reasonable convenience into an authority mismatch.", + "Revocation should be equally ordinary. Closing the project or clearing its session should stop new context gathering and remove retained material according to the product's stated local policy. That statement is intentionally normative: this public journal does not expose private retention details or claim that every temporary copy has been forensically removed. Demonstrating complete cleanup would require platform-specific observation across interruptions, crashes, restarts, and updates. The local design review only supports the decision that withdrawal must be treated as behavior, not decorative interface text." + ] + }, + { + "heading": "Negative cases are the next credible proof", + "paragraphs": [ + "The most informative access tests begin outside the happy path. A useful review would open one project, request material from another, switch projects during an unfinished action, restore a session after the project moved, and attempt operations through indirect references. The expected result should remain narrow and intelligible: no silent widening, no reuse of stale authority, and a clear route back to an explicit choice. Accessibility belongs in that proof as well, because consent that cannot be understood or reversed with a keyboard is not meaningful consent.", + "Passing local cases would still be only one rung in the evidence ladder. Public distribution needs clean-machine installation, operating-system permission review, update and uninstall behavior, representative user testing, and independent examination of boundary failures. Hyoka Hanesu currently explores repository access as an explicit, visible product decision. Notarization, universal containment, production reliability, and safety against every misuse of an authorized tool require evidence beyond the private prototype." + ] + } + ], + "relatedSlugs": [ + "hyoka-context-budgets", + "hyoka-provider-boundaries", + "gy-git-trust-boundaries" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Context Budgets Are a Product Boundary", + "slug": "hyoka-context-budgets", + "excerpt": "Context is a finite, user-visible selection of instructions, conversation, project evidence, and tool results, so its budget belongs in product behavior rather than hidden model arithmetic.", + "status": "published", + "date": "2026-07-01", + "category": "Hyoka Hanesu", + "project": "hyoka-hanesu", + "tags": [ + "Context budgets", + "Selection policy", + "Visible limits" + ], + "placement": "build-business", + "visual": { + "variant": "context-rings", + "alt": "Animated dither rings allocating a finite context budget around a focused question" + }, + "body": [ + { + "heading": "Context is an editorial decision", + "paragraphs": [ + "An assistant never reasons over an entire working world at once. It receives a selection: current instructions, recent conversation, excerpts from the chosen project, and results returned by approved tools. Calling that bundle ‘context’ can make it sound automatic, but every inclusion and omission changes the answer. Hyoka Hanesu treats the selection as an editorial product decision. The system should gather enough evidence to support the current question while resisting the tempting fiction that more material is always better or that an unseen limit has no effect on meaning.", + "Context assembly and budgeting appear as explicit concerns in the approved local product record. Private prompts, project excerpts, machine limits, and service settings are neither published nor needed to explain that principle. The observation cannot support universal answer quality, benchmark leadership, or predictable resource use in a deployed service. It supports a smaller proposition: a repository assistant is easier to understand when the product owns what it selects, what it leaves out, and how it communicates the difference." + ] + }, + { + "heading": "Budget the evidence and expose the omissions", + "paragraphs": [ + "A single total hides competing responsibilities. Instructions define the operating boundary; conversation carries the person's current intent; repository excerpts provide evidence; tool results report new observations; and the assistant needs room to produce a useful response. If any one category can consume the full allowance, the others become accidental casualties. A practical budget therefore reserves space by role and prioritizes current, directly relevant evidence over repeated background. The exact numbers may vary by backend, but the product policy should remain explainable without exposing internal calculations.", + "This layered view also prevents large outputs from becoming authority merely because they are large. A verbose command result may contain less useful evidence than a short focused excerpt, and a long conversation may repeat assumptions that the current project contradicts. Selection should account for provenance, recency, and relevance, not just byte order. The reviewed design notes point in that direction, but this article does not assert a perfected ranking system. Representative tasks and deliberate adversarial cases would be needed to show whether the policy consistently preserves the evidence that matters.", + "When a budget fills, silent truncation is the most damaging response. It lets the interface imply continuity while removing the very definition, decision, or error that explains the next answer. A better product marks that some material was not carried forward, summarizes only when the source remains identifiable, and offers a way to refocus or retrieve the missing evidence. The person should not need to reverse-engineer a sudden change in tone to discover that an earlier constraint fell outside the current window.", + "Visibility does not require flooding the interface with token counters. Human language can describe whether the assistant used the whole selected project, a focused set of files, a shortened tool result, or a condensed conversation. The important promise is semantic: the product must not present an incomplete selection as complete knowledge. Local tests can verify deterministic trimming and interface notices for constructed inputs. They cannot prove that every real project, language, or model will interpret a summary faithfully, so that broader assurance remains outside this journal." + ] + }, + { + "heading": "Backend changes must not erase the contract", + "paragraphs": [ + "Different model paths may accept different context sizes and may count the same material differently. If the interface simply inherits those differences, changing a backend can unpredictably remove conversation, admit larger tool results, or crowd out the response. Hyoka Hanesu instead needs a product-level contract that can be mapped onto each available capability. The contract can adapt its totals, but it should preserve ordering rules, protected instruction space, disclosure of omissions, and a minimum allowance for a coherent answer.", + "A stable contract does not imply equivalent intelligence. Two models can receive the same carefully selected evidence and still produce different interpretations, latency, or language. This article makes no claim of model parity and offers no provider performance comparison. It argues only that the selection boundary should remain under product control so backend variability does not become invisible behavior drift. Proving that mapping would require the supported backends to be exercised against the same context cases in the intended release environment, with differences recorded rather than averaged away." + ] + }, + { + "heading": "A budget earns trust through repeatable pressure tests", + "paragraphs": [ + "The next credible test set should include a long conversation with one decisive early constraint, a large project with one relevant definition, an oversized tool result, repeated content, conflicting recent evidence, and a backend with a smaller allowance. Each case should record what was selected, what was dropped, what the person was told, and whether the answer still cites the governing evidence. Reduced-motion, keyboard, and narrow-screen behavior matter too, because a disclosure that disappears in a particular interface state is not a reliable product boundary.", + "Focused local cases can support the selection algorithm and its presentation, not universal model quality or production resource guarantees. Clean release builds, representative workloads, memory and latency observation, backend failure exercises, and independent review of omission behavior belong to stronger evidence. The product policy currently treats context budgets as visible. It offers no basis for saying every answer contains all relevant knowledge, summaries are lossless, or a private prototype is operationally ready for the public." + ] + } + ], + "relatedSlugs": [ + "hyoka-opt-in-repository-access", + "hyoka-provider-boundaries", + "insuja-permission-safe-search-feed" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Local Models and Remote Providers Need an Honest Boundary", + "slug": "hyoka-provider-boundaries", + "excerpt": "A shared assistant interface should say when work stays on the machine, when selected material may cross a service boundary, and which capabilities genuinely differ between those paths.", + "status": "published", + "date": "2026-06-30", + "category": "Hyoka Hanesu", + "project": "hyoka-hanesu", + "tags": [ + "Backend choice", + "Data boundaries", + "Capability negotiation" + ], + "placement": "recent", + "visual": { + "variant": "signal-window", + "alt": "Animated dither gate separating a local model field from a remote processing field" + }, + "body": [ + { + "heading": "Backend choice changes the journey of the data", + "paragraphs": [ + "A local model and a remote provider may both accept a prompt and stream an answer, but the similarity ends at the interface. Local processing keeps the main inference path on the person's machine and competes for local resources. Remote processing sends a deliberately assembled request beyond that machine and depends on a service boundary. Hyoka Hanesu should make that distinction visible before a project excerpt becomes part of a request. A backend selector is therefore a data-path decision, not merely a preference for one model name over another.", + "The approved local product direction separates these paths without disclosing prompts, credentials, service settings, machine details, or project contents. What a provider retains, how a production service is configured, and whether a local runtime is isolated from every other process remain outside that record. Those questions require provider documentation, verified deployment settings, and environment-specific observation. Here the claim is confined to product behavior: the interface must present the chosen path honestly and keep consent tied to it." + ] + }, + { + "heading": "Capabilities should be discovered, not imagined", + "paragraphs": [ + "Backends can differ in available context, supported tools, streaming behavior, cancellation, structured output, and failure reporting. Pretending those differences do not exist produces fragile behavior: a control appears available, the request begins, and only then does the person learn that the selected path cannot honor it. A more predictable assistant establishes capabilities first and shapes the interface around what is actually available. Unsupported actions should be disabled or explained before work starts rather than translated into a vague downstream error.", + "Capability discovery also needs conservative defaults. An unknown response should not be interpreted as permission to use the richest feature set, and a backend change should invalidate assumptions learned from the previous one. The first-party notes indicate that backend differences are part of the product model, but this public account does not certify every capability mapping. A release claim would require repeated checks against each supported path, including version changes, partial responses, cancellation, missing features, and recovery after an interrupted stream." + ] + }, + { + "heading": "Disclosure belongs before transmission", + "paragraphs": [ + "When remote processing is selected, the interface should describe the categories of material prepared for the request: current instructions, relevant conversation, chosen project excerpts, and approved tool results. It need not reveal sensitive content a second time, but it should make the scope intelligible and let the person cancel or narrow it. Local processing deserves equally careful language; ‘local’ should describe where inference is intended to occur, not become a sweeping promise that no component ever performs networking or writes temporary state.", + "The product should also exclude obvious credentials and unrelated private material before either path receives context. That is defense in depth, not permission to gather broadly and filter later. Explicit repository scope and context budgets remain the earlier boundaries. This journal records the intended ordering without claiming a comprehensive secret detector, legal compliance, or zero disclosure risk. Stronger assurance would require representative sensitive fixtures, network observation, retention review, and independent attempts to make disallowed material cross the chosen boundary." + ] + }, + { + "heading": "One interface must not promise identical behavior", + "paragraphs": [ + "Consistency is valuable when it preserves understandable controls: send, stop, retry, inspect tool intent, and change the selected project. It becomes misleading when the same surface implies that local and remote backends have equal quality, latency, privacy properties, or tool support. Hyoka Hanesu can keep the conversation model familiar while naming meaningful differences near the decision that exposes them. A graceful fallback should ask for a new choice when behavior changes materially, not silently move work to another path to keep the screen busy.", + "Failure semantics are part of that honesty. If a local model is unavailable, the product should not contact a remote service automatically; if a remote request fails, it should not replay private context through a different service without renewed intent. Retrying the same path may still need safeguards against duplicated side effects from tools. These are design requirements distilled from local work, not evidence of complete implementation in a public release. Offline, degraded-service, cancellation, and backend-switch cases remain necessary verification work." + ] + }, + { + "heading": "Proof must follow each side of the boundary", + "paragraphs": [ + "A credible verification matrix would run the same bounded tasks through every supported backend and observe data flow, context selection, visible capabilities, cancellation, errors, and backend changes. The local path should be exercised without external connectivity; the remote path should be inspected to confirm that only the disclosed request leaves the machine. Tests should also cover unavailable models, smaller context allowances, interrupted streams, stale capability information, and attempts to trigger an automatic fallback. The expected differences should be documented rather than treated as noise.", + "Even a passing matrix would not prove provider privacy, equivalent model behavior, a notarized distribution, or live service reliability. Those questions require the actual release and operating environment, plus current provider commitments where relevant. The private local record supports designing local and remote paths as distinct, visible boundaries under one interface. Production configuration, external service behavior, and distribution readiness remain separate, unverified evidence classes." + ] + } + ], + "relatedSlugs": [ + "hyoka-opt-in-repository-access", + "hyoka-context-budgets", + "insuja-identity-assurance-separation" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Building at Git Trust Boundaries in Assembly", + "slug": "gy-git-trust-boundaries", + "excerpt": "An assembly Git prototype makes every length, delimiter, file transition, and process boundary consequential, so parsing limits and interoperability must be visible design commitments.", + "status": "published", + "date": "2026-06-29", + "category": "gy", + "project": "gy", + "tags": [ + "Git boundaries", + "Bounded parsing", + "Assembly research" + ], + "placement": "stories", + "visual": { + "variant": "terminal-rain", + "alt": "Animated dither terminal stream passing through bounded Git parsing gates" + }, + "body": [ + { + "heading": "Assembly removes comforting ambiguity", + "paragraphs": [ + "A high-level Git client can still mishandle input, but its libraries usually hide many decisions about allocation, strings, processes, and file access. An assembly prototype meets those decisions directly. Every incoming length needs a destination, every delimiter needs a search bound, and every borrowed convention needs an explicit failure path. That pressure is valuable research because it makes trust boundaries difficult to ignore. It is also dangerous if small successful examples are mistaken for broad compatibility or memory safety before the surrounding assumptions have been challenged.", + "gy's approved private research record treats parsing and runtime boundaries as first-class questions while investigating Git and forge behavior. This entry publishes no source location, machine detail, unpublished test artifact, infrastructure value, or operational identifier. The local observation supports the research framing, not a qualified release, compatibility with all Git behavior, or protection against hostile input. Reproducible public evidence and independent scrutiny would be needed for those stronger conclusions." + ] + }, + { + "heading": "Parsing and runtime both begin with bounded trust", + "paragraphs": [ + "Git-shaped input arrives through configuration, references, object metadata, packetized exchanges, command arguments, and files whose contents may be larger or stranger than a friendly fixture. A bounded implementation decides maximum lengths, valid character sets, termination rules, and arithmetic behavior before copying or advancing a pointer. It rejects incomplete and oversized input without using a partial value as authority. The goal is not to accept every possible form; it is to make the accepted subset deliberate and ensure refusal does not corrupt state or expose unrelated memory.", + "A parser budget also needs composition. Two individually bounded fields can still overflow a shared buffer when combined, and a valid count can become unsafe after multiplication or alignment. End-of-input, embedded separators, repeated headers, and conflicting declarations deserve explicit outcomes. The design journal records this discipline as intent and local work, not as formal proof. Sanitized fixtures and focused tests can demonstrate named cases, but comprehensive hostile-input confidence would require fuzzing, instrumentation, architecture review, and a maintained account of the formats gy intentionally does not support.", + "A prototype often succeeds while launched from its development checkout because templates, static assets, and helper data happen to be nearby. An installed command runs under a different working directory and should not depend on the caller standing in a particular place. It needs a clear rule for locating its own packaged resources, distinguishing user configuration from immutable assets, and failing safely when either is absent. That is a trust boundary because an uncontrolled working directory must not replace trusted program material merely by containing a familiar filename.", + "Configuration follows the same principle. Environment values and files are untrusted inputs even when they were written by the same person earlier. The program should parse only the options it understands, apply a documented precedence, and avoid turning an empty or malformed value into a broad filesystem target. These are public-safe design requirements, not a disclosure of gy's private layout. Local install exercises can support them on one candidate build, but packaging across clean systems and upgrade or removal behavior remains separate proof." + ] + }, + { + "heading": "Interoperability lives between implementations", + "paragraphs": [ + "Producing bytes that resemble Git output is not the same as interoperating with the wider ecosystem. Another implementation may order fields differently, omit an optional marker, advertise an unfamiliar capability, split a response at another boundary, or reject a shortcut tolerated by a local fixture. gy therefore needs tests that exchange real artifacts with independent implementations and compare semantic results, not only snapshots of its own output. The boundary includes failure behavior: an unsupported feature should be named and refused without leaving a misleading partial repository state.", + "Networked forge behavior widens the matrix further through redirects, authentication challenges, interrupted transfers, retries, and responses that are syntactically valid but semantically inconsistent. This article does not claim live service compatibility or reproduce private endpoint information. It argues that reference-client round trips, hermetic local peers, and explicitly approved external checks answer different questions and should remain labeled. A green hermetic exchange proves a useful contract; it cannot by itself establish current interoperability with every remote service or configuration." + ] + }, + { + "heading": "The boundary report should include what failed", + "paragraphs": [ + "Research becomes credible when unsupported and failing cases are recorded beside successful ones. A useful gy qualification report would list accepted input envelopes, rejected forms, independent round trips, interruption behavior, installed-runtime checks, and any profile that could not run in the available environment. It should preserve enough deterministic detail for another reviewer to repeat the public cases without revealing private machine state. Accessibility and presentation also matter for any served interface, but a polished screen must remain separate from the correctness of the Git operations behind it.", + "The next proof should combine bounded-parser tests, generated malformed inputs, independent interoperability, clean installation, resource lookup from unrelated working directories, failure recovery, and outside review. ‘Research prototype’ remains the evidence-aligned status while those gates are open. Assembly exposes assumptions with unusual clarity; it does not automatically remove them. Memory safety, universal Git compatibility, production suitability, external review closure, and a qualified gy release all require publishable results from that broader matrix." + ] + } + ], + "relatedSlugs": [ + "gy-qualification-before-release", + "hyoka-opt-in-repository-access", + "requisia-private-object-delivery" + ], + "verifiedAt": "2026-07-17" + }, + { + "title": "Qualification Evidence Before Release Language", + "slug": "gy-qualification-before-release", + "excerpt": "A research prototype earns stronger release language only when build, conformance, interoperability, packaging, recovery, and independent-review evidence are reported as separate gates.", + "status": "published", + "date": "2026-06-28", + "category": "gy", + "project": "gy", + "tags": [ + "Release qualification", + "Evidence gates", + "Prototype status" + ], + "placement": "research", + "visual": { + "variant": "cost-contours", + "alt": "Animated dither signal window separating prototype milestones from release qualification" + }, + "body": [ + { + "heading": "Progress and release answer different questions", + "paragraphs": [ + "A prototype can compile, complete a compelling scenario, and teach its author something important without being ready for other people to rely on. Those accomplishments answer whether the idea works under known conditions. Release language answers a broader question: can a defined artifact be installed, exercised, diagnosed, updated, and removed across its supported environment with known limitations? gy benefits from preserving that distinction because an assembly implementation can look dramatically complete in a narrow demonstration while still carrying untested assumptions at every external boundary.", + "The approved record supports two limited statements: gy has meaningful private research progress, and qualification is an explicit concern. Private source, machine details, phase records, infrastructure values, and unpublished results stay outside the entry. Local evidence is not promoted into release status; strict profiles are not said to pass, production suitability is not asserted, and independent review is not presented as complete. The purpose here is to describe the evidence structure required before stronger language becomes responsible." + ] + }, + { + "heading": "Qualification is a stack of named gates", + "paragraphs": [ + "The first gate establishes a reproducible build from declared inputs. Focused tests then exercise bounded units and failure cases. Conformance checks compare behavior with written requirements, while interoperability exchanges artifacts with an independent implementation. Packaging proves that the candidate carries the resources it needs outside a development checkout. Installation and removal verify the supported lifecycle on a clean target. Recovery exercises interruptions and retries. Each gate narrows a different uncertainty, so one green layer should never silently stand in for the layers above it.", + "A useful report records the candidate identity, environment class, commands or procedures, expected result, observed result, and disposition for every gate. Public evidence must remain sanitized and reproducible; private operational data is neither necessary nor appropriate. ‘Not run’ and ‘blocked’ are valid outcomes when stated plainly. They are not failures to be hidden, and they are not passes. This separation lets future work resume at the actual open boundary instead of rebuilding confidence from a summary that flattened several kinds of evidence into one optimistic status." + ] + }, + { + "heading": "A clean environment challenges hidden dependencies", + "paragraphs": [ + "Development machines accumulate compilers, helper tools, environment values, cached assets, and familiar working directories. A candidate that succeeds there may depend on state absent from the intended target. Qualification therefore needs a clean, representative environment created from the published prerequisites. The artifact should start from an unrelated working directory, locate only its packaged resources and documented configuration, reject missing requirements clearly, and leave the system in a known state after removal. Repeating the lifecycle reveals assumptions that an in-place run cannot see.", + "Architecture and operating-system boundaries matter just as much. A build produced on one machine may target another runtime, so inspecting the artifact and exercising it in the intended environment answer different questions. Emulation can provide useful evidence when labeled, but it does not automatically replace native-host behavior. The private gy work may include local candidates and constrained test environments; this journal does not turn those into distribution proof. Supported-platform qualification still requires clean evidence for the exact artifact and lifecycle being described." + ] + }, + { + "heading": "Strict profiles should fail closed", + "paragraphs": [ + "A qualification profile is valuable only when its prerequisites and success criteria are explicit. If a required host, independent peer, security instrument, or review artifact is unavailable, the profile should stop with a precise blocked outcome. Substituting a lighter check may help diagnose progress, but it creates a different evidence class and must receive a different label. This is especially important for low-level work, where a normal functional run cannot establish memory safety, malformed-input resilience, or conformance at the edges of the accepted format.", + "Failures should retain actionable context without leaking private machine or service information. The report can identify the gate, expected capability, sanitized symptom, and next proof needed. It should not publish credentials, internal locations, provider identifiers, or mutable operational notes. Local remediation followed by a rerun can close the named case, but it does not retroactively validate unrelated profiles. The reviewed design posture favors that fail-closed accounting; public confidence still depends on seeing repeatable results from the eventual candidate rather than trusting an unpublished private ledger." + ] + }, + { + "heading": "Release language is the final decision gate", + "paragraphs": [ + "Once the evidence stack is complete, release wording should name the supported scope and remaining limitations rather than declaring the prototype simply ‘ready.’ A responsible handoff can state which artifact was qualified, on which environment class, against which interoperability peers, with which lifecycle and recovery cases. It can also say what was excluded. That precision makes a smaller release more trustworthy than a broad promise. Versioning, checksums, licensing, public documentation, and an accessible issue path belong in this final gate because distribution creates responsibilities beyond code execution.", + "Describing the threshold does not mean gy has crossed it. The next credible step is a candidate-specific qualification packet reviewed by someone other than the implementer, followed by publication only when required gates pass or remaining exclusions are explicitly accepted. ‘Research prototype’ remains the status. A qualified release, production suitability, universal compatibility, memory-safety proof, strict-profile completion, and external security closure all await candidate-specific evidence." + ] + } + ], + "relatedSlugs": [ + "gy-git-trust-boundaries", + "requisia-composite-readiness", + "hyoka-provider-boundaries" + ], + "verifiedAt": "2026-07-17" + }, + { + "slug": "reviewing-the-next-public-system", + "title": "Reviewing the next public system", + "excerpt": "A draft checklist for turning a public repository into a bounded, source-backed Cumulus field note without overstating deployment or production evidence.", + "status": "draft", + "date": "2026-06-22", + "category": "Editorial", + "tags": [ + "Research method", + "Public sources" + ], + "placement": "research", + "visual": { + "variant": "workspace-beacon", + "alt": "Dither study for a future public-source review" + }, + "body": [ + { + "heading": "Start at the public boundary", + "paragraphs": [ + "A repository can support a useful field note only when the cited material is anonymously reachable and the publication boundary is explicit. Local context may identify what deserves attention, but it cannot become a public claim until the matching source, history, or documentation is available without privileged access.", + "The first review therefore records the repository snapshot, the exact files that support the topic, and the difference between source behavior and deployed behavior. A source file can prove that a guard exists in code; it cannot prove the production account, network, or operator configuration currently exercises it." + ] + }, + { + "heading": "Trace the complete path", + "paragraphs": [ + "A robust analysis reads the owning documentation, immediate callers, focused tests, and failure paths instead of quoting a single attractive function. The goal is to explain the system boundary, the design decision, and the operational tradeoff in language that another reader can check against the linked code.", + "Stable commit links keep that review reproducible. Mutable branch links are convenient during drafting, but a published note should preserve the source state that was actually reviewed so a later refactor does not silently change the evidence beneath the article." + ] + }, + { + "heading": "Publish limits with the result", + "paragraphs": [ + "Every article should name what remains unproven: a mock does not establish provider compatibility, a migration does not establish live application, and a security control does not establish the absence of vulnerabilities. Those limits make the analysis stronger because they prevent one narrow artifact from absorbing unrelated claims.", + "This entry remains a draft until a specific public repository, commit, source trail, and cross-article backlink set are selected. Draft isolation is intentional; the public archive and routes must expose only posts that have passed the same source and structure checks as the rest of the corpus." + ] + } + ], + "relatedSlugs": [ + "requisia-organization-scoped-registers", + "insuja-typed-tenant-boundaries" + ] + } +] diff --git a/src/content/posts.test.ts b/src/content/posts.test.ts index 3924bae..0c7f5fd 100644 --- a/src/content/posts.test.ts +++ b/src/content/posts.test.ts @@ -14,10 +14,10 @@ import { import { FIRST_PARTY_JOURNAL_NOTICE } from "./focused-posts"; const EXPECTED_PROJECTS = new Map([ - ["requisia", { category: "Requisia", count: 8 }], - ["insuja", { category: "Insuja", count: 7 }], - ["hyoka-hanesu", { category: "Hyoka Hanesu", count: 3 }], - ["gy", { category: "gy", count: 2 }], + ["requisia", "Requisia"], + ["insuja", "Insuja"], + ["hyoka-hanesu", "Hyoka Hanesu"], + ["gy", "gy"], ]); function editablePosts(): Post[] { @@ -35,20 +35,15 @@ function editablePosts(): Post[] { } describe("POSTS", () => { - it("publishes exactly twenty journals in the approved four-project split", () => { - expect(publishedPosts).toHaveLength(20); + it("publishes a valid, ordered catalog without a fixed post count", () => { + expect(publishedPosts.length).toBeGreaterThan(0); expect(new Set(POSTS.map((post) => post.slug)).size).toBe(POSTS.length); - expect(POSTS.filter((post) => post.status === "draft")).toHaveLength(1); - for (const [project, expected] of EXPECTED_PROJECTS) { + for (const [project, category] of EXPECTED_PROJECTS) { const projectPosts = publishedPosts.filter((post) => post.project === project); - expect(projectPosts, project).toHaveLength(expected.count); - expect(projectPosts.every((post) => post.category === expected.category)).toBe(true); + expect(projectPosts.every((post) => post.category === category)).toBe(true); } - expect(new Set(publishedPosts.map((post) => post.project))).toEqual( - new Set(EXPECTED_PROJECTS.keys()), - ); expect( POSTS.every( (post, index) => index === 0 || POSTS[index - 1].date >= post.date, @@ -62,34 +57,36 @@ describe("POSTS", () => { const sectionCounts = new Set(); for (const post of publishedPosts) { - expect(post.title.trim().length).toBeGreaterThan(10); - expect(post.excerpt.trim().length).toBeGreaterThan(90); - expect(post.project?.trim()).not.toBe(""); - expect(post.tags.length).toBeGreaterThanOrEqual(3); + expect(post.title.trim().length).toBeGreaterThan(5); + expect(post.excerpt.trim().length).toBeGreaterThan(40); + if (post.category !== "Editorial") expect(post.project?.trim()).not.toBe(""); + expect(post.tags.length).toBeGreaterThanOrEqual(2); expect(new Set(post.tags.map((tag) => tag.toLocaleLowerCase("en-US"))).size) .toBe(post.tags.length); const bodyWords = countBodyWords(post.body); - expect(bodyWords, post.slug).toBeGreaterThanOrEqual(600); + expect(bodyWords, post.slug).toBeGreaterThanOrEqual(50); expect(post.readingTime, post.slug).toBe(calculateReadingTime(post.body)); expect(post.visual.alt.trim().length).toBeGreaterThan(24); - expect(post.body.length).toBeGreaterThanOrEqual(3); + expect(post.body.length).toBeGreaterThanOrEqual(1); expect(post.body.length).toBeLessThanOrEqual(6); expect(post.verifiedAt).toMatch(/^\d{4}-\d{2}-\d{2}$/); sectionCounts.add(post.body.length); - const completeBody = post.body - .flatMap((bodySection) => bodySection.paragraphs) - .join(" "); - expect(completeBody, post.slug).toMatch( - /evidence|first-party|private|production|deployment|public/i, - ); + if (post.category !== "Editorial") { + const completeBody = post.body + .flatMap((bodySection) => bodySection.paragraphs) + .join(" "); + expect(completeBody, post.slug).toMatch( + /evidence|first-party|private|production|deployment|public/i, + ); + } for (const bodySection of post.body) { expect(bodySection.heading.trim().length).toBeGreaterThan(4); - expect(bodySection.paragraphs.length).toBeGreaterThanOrEqual(2); + expect(bodySection.paragraphs.length).toBeGreaterThanOrEqual(1); for (const paragraph of bodySection.paragraphs) { - expect(paragraph.trim().length).toBeGreaterThanOrEqual(80); + expect(paragraph.trim().length).toBeGreaterThanOrEqual(40); const normalized = paragraph.trim().replace(/\s+/g, " "); expect( seenParagraphs.get(normalized), @@ -128,10 +125,6 @@ describe("POSTS", () => { }); it("uses the first-party journal boundary without invented source links", () => { - for (const post of publishedPosts) { - expect(post.sourceLinks ?? [], post.slug).toEqual([]); - } - const serialized = JSON.stringify(POSTS); expect(serialized).not.toMatch( /\/Users\/|\/private\/|localhost|127\.0\.0\.1|ocque41/i, @@ -162,7 +155,6 @@ describe("POSTS", () => { const publishedSlugs = new Set(publishedPosts.map((post) => post.slug)); for (const post of POSTS) { - expect(post.relatedSlugs?.length ?? 0, post.slug).toBeGreaterThanOrEqual(2); expect(new Set(post.relatedSlugs).size).toBe(post.relatedSlugs?.length); for (const relatedSlug of post.relatedSlugs ?? []) { expect(relatedSlug).not.toBe(post.slug); @@ -172,6 +164,35 @@ describe("POSTS", () => { } } }); + + it("accepts a short Editorial post with a generated Cumulus visual", () => { + const posts = editablePosts(); + const body = [{ + heading: "A small public note", + paragraphs: [ + "A focused thought.", + ], + }]; + posts.unshift({ + slug: "a-small-public-note", + title: "A small public note", + excerpt: "A compact editorial that keeps the author’s facts while applying the Cumulus publishing structure.", + status: "published", + date: "2026-07-18", + category: "Editorial", + tags: ["Publishing", "Editorial"], + readingTime: calculateReadingTime(body), + placement: "recent", + visual: { + variant: "signal-window", + alt: "Animated dither signal window framing a compact editorial note", + }, + body, + verifiedAt: "2026-07-18", + }); + + expect(validatePosts(posts)).toEqual([]); + }); }); describe("published post selectors", () => { @@ -242,7 +263,7 @@ describe("validatePosts", () => { posts[0] = { ...posts[0], date: "0000-00-00", - body: [{ heading: "", paragraphs: ["Only one short paragraph."] }], + body: [{ heading: "", paragraphs: ["Short"] }], }; const issues = validatePosts(posts); @@ -250,13 +271,13 @@ describe("validatePosts", () => { `${posts[0].slug}: date must be a valid YYYY-MM-DD value.`, ); expect(issues).toContain( - `${posts[0].slug}: body must contain between three and six sections.`, + `${posts[0].slug}: published body must contain at least three words.`, ); expect(issues).toContain( `${posts[0].slug}: body section 1 needs a heading.`, ); expect(issues).toContain( - `${posts[0].slug}: body section 1 needs two substantial paragraphs.`, + `${posts[0].slug}: body section 1 needs at least one substantial paragraph.`, ); expect(issues).toContain( `${posts[1].slug}: posts must be in non-increasing date order.`, diff --git a/src/content/posts.ts b/src/content/posts.ts index a9b5248..c31945d 100644 --- a/src/content/posts.ts +++ b/src/content/posts.ts @@ -1,5 +1,9 @@ -import { FOCUSED_POSTS } from "./focused-posts.js"; -import type { Post, PostBodySection } from "./post-types.js"; +import postsData from "./posts.json" with { type: "json" }; +import { + DITHER_VARIANTS, + type Post, + type PostBodySection, +} from "./post-types.js"; export type { DitherVariant, @@ -10,78 +14,14 @@ export type { PostVisual, } from "./post-types.js"; -const DRAFT_POST: Post = { - slug: "reviewing-the-next-public-system", - title: "Reviewing the next public system", - excerpt: - "A draft checklist for turning a public repository into a bounded, source-backed Cumulus field note without overstating deployment or production evidence.", - status: "draft", - date: "2026-06-22", - category: "Editorial", - tags: ["Research method", "Public sources"], - readingTime: 2, - placement: "research", - visual: { - variant: "workspace-beacon", - alt: "Dither study for a future public-source review", - }, - body: [ - { - heading: "Start at the public boundary", - paragraphs: [ - "A repository can support a useful field note only when the cited material is anonymously reachable and the publication boundary is explicit. Local context may identify what deserves attention, but it cannot become a public claim until the matching source, history, or documentation is available without privileged access.", - "The first review therefore records the repository snapshot, the exact files that support the topic, and the difference between source behavior and deployed behavior. A source file can prove that a guard exists in code; it cannot prove the production account, network, or operator configuration currently exercises it.", - ], - }, - { - heading: "Trace the complete path", - paragraphs: [ - "A robust analysis reads the owning documentation, immediate callers, focused tests, and failure paths instead of quoting a single attractive function. The goal is to explain the system boundary, the design decision, and the operational tradeoff in language that another reader can check against the linked code.", - "Stable commit links keep that review reproducible. Mutable branch links are convenient during drafting, but a published note should preserve the source state that was actually reviewed so a later refactor does not silently change the evidence beneath the article.", - ], - }, - { - heading: "Publish limits with the result", - paragraphs: [ - "Every article should name what remains unproven: a mock does not establish provider compatibility, a migration does not establish live application, and a security control does not establish the absence of vulnerabilities. Those limits make the analysis stronger because they prevent one narrow artifact from absorbing unrelated claims.", - "This entry remains a draft until a specific public repository, commit, source trail, and cross-article backlink set are selected. Draft isolation is intentional; the public archive and routes must expose only posts that have passed the same source and structure checks as the rest of the corpus.", - ], - }, - ], - relatedSlugs: [ - "requisia-organization-scoped-registers", - "insuja-typed-tenant-boundaries", - ], -}; - -export function countBodyWords(body: readonly PostBodySection[]): number { - return body.reduce( - (sectionTotal, bodySection) => - sectionTotal + - bodySection.paragraphs.reduce( - (paragraphTotal, paragraph) => - paragraphTotal + paragraph.trim().split(/\s+/).filter(Boolean).length, - 0, - ), - 0, - ); -} - -export function calculateReadingTime(body: readonly PostBodySection[]): number { - return Math.max(1, Math.ceil(countBodyWords(body) / 220)); -} - -export const POSTS: readonly Post[] = [...FOCUSED_POSTS, DRAFT_POST].map( - (post) => ({ ...post, readingTime: calculateReadingTime(post.body) }), -); - const SLUG_PATTERN = /^[a-z0-9]+(?:-[a-z0-9]+)*$/; const DATE_PATTERN = /^\d{4}-\d{2}-\d{2}$/; -const EXPECTED_PROJECT_COUNTS = new Map([ - ["requisia", 8], - ["insuja", 7], - ["hyoka-hanesu", 3], - ["gy", 2], +const DITHER_VARIANT_SET = new Set(DITHER_VARIANTS); +const PROJECT_CATEGORIES = new Map([ + ["requisia", "Requisia"], + ["insuja", "Insuja"], + ["hyoka-hanesu", "Hyoka Hanesu"], + ["gy", "gy"], ]); function normalized(value: string): string { @@ -108,6 +48,30 @@ function isSafeHttpsUrl(value: string): boolean { } } +export function countBodyWords(body: readonly PostBodySection[]): number { + return body.reduce( + (sectionTotal, bodySection) => + sectionTotal + + bodySection.paragraphs.reduce( + (paragraphTotal, paragraph) => + paragraphTotal + paragraph.trim().split(/\s+/).filter(Boolean).length, + 0, + ), + 0, + ); +} + +export function calculateReadingTime(body: readonly PostBodySection[]): number { + return Math.max(1, Math.ceil(countBodyWords(body) / 220)); +} + +const RAW_POSTS = postsData as unknown as readonly Omit[]; + +export const POSTS: readonly Post[] = RAW_POSTS.map((post) => ({ + ...post, + readingTime: calculateReadingTime(post.body), +})); + export function validatePosts(posts: readonly Post[] = POSTS): string[] { const issues: string[] = []; const slugs = new Set(); @@ -115,30 +79,6 @@ export function validatePosts(posts: readonly Post[] = POSTS): string[] { posts.filter((post) => post.status === "published").map((post) => post.slug), ); - if (publishedSlugs.size !== 20) { - issues.push(`Expected exactly 20 published posts, received ${publishedSlugs.size}.`); - } - - for (const [project, expectedCount] of EXPECTED_PROJECT_COUNTS) { - const projectCount = posts.filter( - (post) => post.status === "published" && post.project === project, - ).length; - if (projectCount !== expectedCount) { - issues.push( - `Expected ${expectedCount} published ${project} posts, received ${projectCount}.`, - ); - } - } - const unexpectedProjects = new Set( - posts - .filter((post) => post.status === "published") - .map((post) => post.project) - .filter((project) => !project || !EXPECTED_PROJECT_COUNTS.has(project)), - ); - for (const project of unexpectedProjects) { - issues.push(`Unexpected published project ${project ?? "(missing)"}.`); - } - const featuredCount = posts.filter( (post) => post.status === "published" && post.placement === "featured", ).length; @@ -156,9 +96,15 @@ export function validatePosts(posts: readonly Post[] = POSTS): string[] { if (!isValidDate(post.date)) issues.push(`${label}: date must be a valid YYYY-MM-DD value.`); if (!post.category.trim()) issues.push(`${label}: category is required.`); + if (post.category === "Editorial") { + if (post.project) issues.push(`${label}: Editorial posts cannot set a project.`); + } else if (!post.project || PROJECT_CATEGORIES.get(post.project) !== post.category) { + issues.push(`${label}: project and category must use an approved Cumulus pairing.`); + } + const expectedReadingTime = calculateReadingTime(post.body); - if (!Number.isInteger(post.readingTime) || Math.abs(post.readingTime - expectedReadingTime) > 1) { - issues.push(`${label}: readingTime must track body length at roughly 220 wpm.`); + if (!Number.isInteger(post.readingTime) || post.readingTime !== expectedReadingTime) { + issues.push(`${label}: readingTime must be calculated from body length.`); } if (post.tags.length < 2 || post.tags.some((tag) => !tag.trim())) { issues.push(`${label}: at least two non-empty tags are required.`); @@ -166,24 +112,26 @@ export function validatePosts(posts: readonly Post[] = POSTS): string[] { if (new Set(post.tags.map(normalized)).size !== post.tags.length) { issues.push(`${label}: tags must be unique within a post.`); } - if (!post.visual.variant || !post.visual.alt.trim()) { + if (!DITHER_VARIANT_SET.has(post.visual.variant) || !post.visual.alt.trim()) { issues.push(`${label}: visual variant and alternative text are required.`); } - if (post.body.length < 3 || post.body.length > 6) { - issues.push(`${label}: body must contain between three and six sections.`); + if (post.body.length < 1 || post.body.length > 6) { + issues.push(`${label}: body must contain between one and six sections.`); } - if (post.status === "published" && countBodyWords(post.body) < 600) { - issues.push(`${label}: published body must contain at least 600 words.`); + if (post.status === "published" && countBodyWords(post.body) < 3) { + issues.push(`${label}: published body must contain at least three words.`); } post.body.forEach((bodySection, sectionIndex) => { if (!bodySection.heading.trim()) { issues.push(`${label}: body section ${sectionIndex + 1} needs a heading.`); } if ( - bodySection.paragraphs.length < 2 || - bodySection.paragraphs.some((paragraph) => paragraph.trim().length < 80) + bodySection.paragraphs.length < 1 || + bodySection.paragraphs.some((paragraph) => paragraph.trim().length < 10) ) { - issues.push(`${label}: body section ${sectionIndex + 1} needs two substantial paragraphs.`); + issues.push( + `${label}: body section ${sectionIndex + 1} needs at least one substantial paragraph.`, + ); } }); @@ -196,10 +144,8 @@ export function validatePosts(posts: readonly Post[] = POSTS): string[] { if (sourceKeys.has(key)) issues.push(`${label}: source links must be unique.`); sourceKeys.add(key); } + const related = post.relatedSlugs ?? []; - if (post.status === "published" && related.length < 2) { - issues.push(`${label}: published posts need at least two related backlinks.`); - } if (new Set(related).size !== related.length) { issues.push(`${label}: related slugs must be unique.`); } @@ -220,9 +166,6 @@ export function validatePosts(posts: readonly Post[] = POSTS): string[] { } }); - if (!posts.some((post) => post.status === "draft")) { - issues.push("At least one draft post is required to verify draft isolation."); - } return issues; } diff --git a/src/pages/LogsPage.test.tsx b/src/pages/LogsPage.test.tsx index 5ddc576..8e36ad1 100644 --- a/src/pages/LogsPage.test.tsx +++ b/src/pages/LogsPage.test.tsx @@ -1,7 +1,7 @@ import { cleanup, fireEvent, render, screen, waitFor } from "@testing-library/react"; import { afterEach, beforeEach, describe, expect, it, vi } from "vitest"; -import { searchPublishedPosts } from "@/content/posts"; +import { publishedPosts, searchPublishedPosts } from "@/content/posts"; import { LogsPage } from "./LogsPage"; @@ -19,19 +19,24 @@ afterEach(() => { describe("LogsPage filters", () => { it("applies a category without jumping away from the controls or losing focus", async () => { render(); + const expected = searchPublishedPosts("", "Requisia").length; const requisia = screen.getByRole("button", { name: "Requisia" }); requisia.focus(); fireEvent.click(requisia); - await waitFor(() => expect(screen.getByRole("status")).toHaveTextContent(/^8 entries$/)); + await waitFor(() => + expect(screen.getByRole("status")).toHaveTextContent( + `${expected} entries`, + ), + ); expect(window.location.search).toBe("?category=Requisia"); expect(requisia).toHaveAttribute("aria-pressed", "true"); expect(requisia).toHaveFocus(); expect(window.scrollTo).not.toHaveBeenCalled(); const rows = Array.from(document.querySelectorAll(".post-index-row")); - expect(rows).toHaveLength(8); + expect(rows).toHaveLength(expected); expect(rows.every((row) => row.textContent?.includes("Requisia"))).toBe(true); }); @@ -51,7 +56,11 @@ describe("LogsPage filters", () => { expect(window.location.search).toBe("?q=evidence&category=Requisia"); fireEvent.click(screen.getByRole("button", { name: "Clear filters" })); - await waitFor(() => expect(screen.getByRole("status")).toHaveTextContent(/^20 entries$/)); + await waitFor(() => + expect(screen.getByRole("status")).toHaveTextContent( + `${publishedPosts.length} entries`, + ), + ); expect(window.location.pathname).toBe("/logs"); expect(window.location.search).toBe(""); expect(screen.getByRole("searchbox", { name: "Search logs" })).toHaveValue(""); diff --git a/src/pages/PostPage.test.tsx b/src/pages/PostPage.test.tsx index 0e8a2aa..0901866 100644 --- a/src/pages/PostPage.test.tsx +++ b/src/pages/PostPage.test.tsx @@ -1,7 +1,7 @@ -import { cleanup, render } from "@testing-library/react"; +import { cleanup, render, screen } from "@testing-library/react"; import { afterEach, describe, expect, it, vi } from "vitest"; -import { publishedPosts } from "@/content/posts"; +import { publishedPosts, type Post } from "@/content/posts"; vi.mock("@/components/content/PostComponents", async () => { const actual = await vi.importActual( @@ -36,4 +36,28 @@ describe("PostPage evidence mode", () => { view.unmount(); } }); + + it("renders an Editorial boundary and author-supplied links", () => { + const editorial: Post = { + ...publishedPosts[0], + category: "Editorial", + project: undefined, + sourceLinks: [{ + label: "Supporting source", + href: "https://example.com/source", + }], + }; + + render(); + + expect(screen.getByText("Author-supplied editorial.")).toBeInTheDocument(); + expect(screen.getByRole("link", { name: "Supporting source" })).toHaveAttribute( + "href", + "https://example.com/source", + ); + expect(screen.getByRole("link", { name: "Links and sources" })).toHaveAttribute( + "href", + "#sources", + ); + }); }); diff --git a/src/pages/PostPage.tsx b/src/pages/PostPage.tsx index 27e0af6..ad526cb 100644 --- a/src/pages/PostPage.tsx +++ b/src/pages/PostPage.tsx @@ -38,10 +38,17 @@ export function PostPage({ post }: { post: Post }) { {post.category} -

- {FIRST_PARTY_JOURNAL_NOTICE.label}.{" "} - {FIRST_PARTY_JOURNAL_NOTICE.detail} -

+ {post.category === "Editorial" ? ( +

+ Author-supplied editorial.{" "} + Claims and links are limited to the submitted source and reviewed publication. +

+ ) : ( +

+ {FIRST_PARTY_JOURNAL_NOTICE.label}.{" "} + {FIRST_PARTY_JOURNAL_NOTICE.detail} +

+ )}

{post.title}

{post.excerpt}

    @@ -72,6 +79,11 @@ export function PostPage({ post }: { post: Post }) { {section.heading} ))} + {post.sourceLinks?.length ? ( +
  • + Links and sources +
    • + ) : null} Back to every log @@ -94,6 +106,22 @@ export function PostPage({ post }: { post: Post }) { /> ))} + {post.sourceLinks?.length ? ( +
    +

    Author-supplied references

    +

    Links and sources

    +
      + {post.sourceLinks.map((source, index) => ( +
    1. + {String(index + 1).padStart(2, "0")} + + {source.label} + +
      2. + ))} +
    +
    + ) : null} diff --git a/tests/e2e/public-experience.spec.ts b/tests/e2e/public-experience.spec.ts index ec466b2..39d4ca6 100644 --- a/tests/e2e/public-experience.spec.ts +++ b/tests/e2e/public-experience.spec.ts @@ -16,12 +16,16 @@ import { const PREFERENCES_ENDPOINT = "**/api/notifications/preferences"; -const PROJECT_COUNTS = new Map([ - ["requisia", 8], - ["insuja", 7], - ["hyoka-hanesu", 3], - ["gy", 2], -]); +const PROJECT_COUNTS = new Map( + WORK_PROJECTS.map((project) => [ + project.slug, + publishedPosts.filter((post) => post.project === project.slug).length, + ]), +); +const PROJECT_POST_COUNT = Array.from(PROJECT_COUNTS.values()).reduce( + (total, count) => total + count, + 0, +); async function openNotificationSettings(page: Page): Promise { const trigger = page.getByRole("button", { @@ -107,7 +111,7 @@ test.beforeEach(async ({ page }) => { await mockAnonymousNotificationSession(page); }); -test("the archive contains exactly the 20 canonical project journals", async ({ +test("the archive reflects the validated post catalog", async ({ page, }) => { await seedNotificationPromptMarker(page); @@ -116,8 +120,12 @@ test("the archive contains exactly the 20 canonical project journals", async ({ await expect( page.getByRole("heading", { level: 1, name: "Log index" }), ).toBeVisible(); - await expect(page.getByRole("status")).toHaveText("20 entries"); - await expect(page.locator(".post-index-row")).toHaveCount(20); + await expect(page.getByRole("status")).toHaveText( + `${publishedPosts.length} entries`, + ); + await expect(page.locator(".post-index-row")).toHaveCount( + publishedPosts.length, + ); for (const [project, expectedCount] of PROJECT_COUNTS) { await expect( @@ -136,16 +144,19 @@ test("the archive contains exactly the 20 canonical project journals", async ({ await expect(page.getByRole("status")).toHaveText( `${searchPublishedPosts("Requisia").length} entries matching “Requisia”`, ); - await expect(page.locator(".post-index-row")).toHaveCount(8); + const requisiaCount = searchPublishedPosts("Requisia").length; + await expect(page.locator(".post-index-row")).toHaveCount(requisiaCount); await expect( page.locator(".post-index-row .post-meta > span:nth-of-type(2)").filter({ hasText: /^requisia$/i, }), - ).toHaveCount(8); + ).toHaveCount(requisiaCount); await page.getByRole("button", { name: "Clear filters" }).click(); await expect(page).toHaveURL(/\/logs$/); - await expect(page.getByRole("status")).toHaveText("20 entries"); + await expect(page.getByRole("status")).toHaveText( + `${publishedPosts.length} entries`, + ); await expect(search).toHaveValue(""); }); @@ -164,14 +175,14 @@ test("Public Work presents four internal project records without source links", const projectJournalLinks = page.locator( '.work-project__notes a[href^="/logs/"]', ); - await expect(projectJournalLinks).toHaveCount(20); + await expect(projectJournalLinks).toHaveCount(PROJECT_POST_COUNT); await expect( projectJournalLinks.locator(".work-project__note-plate.dither-artwork"), - ).toHaveCount(20); + ).toHaveCount(PROJECT_POST_COUNT); const projectJournalHrefs = await projectJournalLinks.evaluateAll((links) => links.map((link) => link.getAttribute("href")), ); - expect(new Set(projectJournalHrefs).size).toBe(20); + expect(new Set(projectJournalHrefs).size).toBe(PROJECT_POST_COUNT); for (const project of WORK_PROJECTS) { await expect( diff --git a/tsconfig.vercel.json b/tsconfig.vercel.json index ac1d754..8103fe3 100644 --- a/tsconfig.vercel.json +++ b/tsconfig.vercel.json @@ -7,6 +7,7 @@ "noEmit": true, "module": "NodeNext", "moduleResolution": "NodeNext", + "resolveJsonModule": true, "types": ["node"] }, "include": ["api/**/*.ts", "server/**/*.ts", "src/content/posts.ts"],