@dailephd/my-frontend-observer 0.9.0 → 0.10.0

package/docs/ROADMAP.md

@@ -1,7 +1,7 @@
 # Roadmap
 
-v0.9 status: released as v0.9.0 and published to npm as
-`@dailephd/my-frontend-observer@0.9.0`. v0.10 remains future work.
+Current release: v0.10.0, Full Visual Human–LLM Frontend Change Workflow.
+The v0.9.1 PWA hard-gate isolation maintenance release is preserved in history.
 
 This is a version-level specification, not an implementation checklist.
 Concrete steps and sequencing are designed only when a version begins, after
@@ -890,8 +890,61 @@ seven implementation prompts, and batch gates live in
 version-level decisions above plus current repository inspection; this roadmap
 intentionally does not duplicate batch-by-batch instructions.
 
+## v0.9.1 — PWA Hard-Gate Isolation and Reproducible Security Acceptance
+
+Current status: released as `0.9.1`. The concrete implementation plan remains
+frozen in `docs/plans/v0.9.1-implementation-plan.md`.
+This patch is maintenance work over the released v0.9.0 codebase and does not
+change the v0.9 product capability model.
+
+Objective/problem: make the PWA server-down hard acceptance proof genuinely
+self-contained. The released test in `tests/browser/pwaHardening.test.ts`
+passes in the normal full-file/full-suite order but fails when selected alone
+because it can inherit service-worker/cache state from earlier tests and from a
+fixed persistent Chromium profile. That is a test-isolation defect. It is not
+evidence that the released PWA serves stale evidence or otherwise violates the
+runtime safety contract.
+
+Required capabilities: the hard gate must create and own fresh disposable
+evidence state, a fresh viewer server, a fresh persistent Chromium profile, a
+fresh BrowserContext, and its page; independently establish service-worker
+registration and activation; prove that the current page is controlled by the
+worker; prove the application shell needed for offline reload is precached;
+prove `/api/` evidence responses are absent from Cache Storage; prove live
+evidence is visible before shutdown; prove the server/network is actually
+unavailable after shutdown; reload from the precached shell; then prove an
+explicit unavailable state is shown and previously fetched evidence is absent.
+All owned resources must be cleaned up even on failure.
+
+Constraints and contracts: the hard/security acceptance experiment must not
+depend on another `it()`, test order, a previously warmed Cache Storage, or a
+profile retained under `.my-dev-kit-workflow`. Tests explicitly designated
+`HARD GATE`, `SECURITY GATE`, or `ACCEPTANCE GATE` must be independently
+runnable from fresh state. The dedicated isolated hard-gate command and the
+normal full browser/security suites must exercise the same product behavior.
+
+Exclusions: no production PWA/service-worker semantic change is authorized
+merely to make the test green; no new user-facing feature, evidence schema,
+CLI command, package dependency, tutorial behavior, or v0.10 capability belongs
+in this patch. If the corrected clean-state experiment exposes a genuine
+runtime defect, implementation must stop and reclassify the work as a product
+defect before changing production behavior.
+
+Acceptance: the PWA hard gate passes when run by itself from a fresh process and
+fresh temporary profile, passes in the complete `pwaHardening.test.ts` file,
+and passes in the normal browser/security validation chain. The test must prove
+its own service-worker control, shell-cache, API-cache-exclusion, network-down,
+and stale-evidence-absence prerequisites rather than infer them from another
+test. Temporary browser profiles and evidence roots must be removed after both
+success and failure. Release-readiness validation must preserve the v0.9.0
+product/package behavior while proving the stronger test-isolation invariant.
+
 ## v0.10 — Full Visual Human–LLM Frontend Change Workflow
 
+Current status: released as `0.10.0`. The frozen implementation authority
+remains
+`docs/plans/v0.10-implementation-plan.md`.
+
 Objective/problem: complete the visual communication branch by combining the
 already operational coding-agent loop with graphical inspection, external design
 references, structured annotation, and the v0.8.1 project-level acceptance

package/docs/SECURITY.md

@@ -219,10 +219,12 @@ protect against other software already running as the same user.
   `content-type: application/json`, identity `content-encoding` only, a
   256 KiB (`262144` byte) body limit, valid JSON, and a closed request shape
   with unknown fields rejected.
-- **Exactly three `POST` routes**: `POST /api/annotations`,
+- **Exactly three v0.9 `POST` routes**: v0.9 introduced
+  `POST /api/annotations`,
   `POST /api/annotations/:handle/promote-contract`, and
   `POST /api/annotations/:handle/materialize-reference`. `PUT`, `PATCH`, and
-  `DELETE` stay unsupported everywhere. Any other `POST` returns `405`.
+  `DELETE` stay unsupported everywhere. The implemented, unreleased v0.10
+  routes extend this same gate as described below.
 - **No permissive CORS**: no `Access-Control-Allow-*` headers are sent, so a
   page from any other origin cannot read the capability or send a JSON
   authoring request. A real-Chromium test proves this for all three routes.
@@ -249,12 +251,32 @@ protect against other software already running as the same user.
   `.tmp-*` directories, so a partially written artifact is never presented as
   evidence.
 
+## v0.10 Visual Change authoring boundary
+
+v0.10 extends only the project-aware guarded `POST` surface. It adds explicit
+reference approval and actual/reference workflow creation, plus workflow
+activation, canonical check, restore, handoff preparation, human review, and
+recording of already-existing governance results. Every route reuses the same
+exact Host, Origin, memory-only capability token, JSON content type,
+compression rejection, body limit, closed request-shape, serialized-write,
+path-containment, and `no-store` controls. Standalone `view --root` remains
+read-only, and the service worker continues to cache no `/api/` response.
+
+The additional surface does not grant source-edit or external-process
+authority. Observer never edits target source, executes a coding agent, invokes
+my-dev-kit, or contacts/controls an orchestrator. Optional orchestrator fields
+are bounded traceability metadata only. Handoffs are generated in memory and
+are not a persisted evidence family. Review acceptance requires the latest
+canonical Observer check to be PASS; it cannot approve a baseline/reference or
+restore project acceptance. Governance recording can reference only a
+separately persisted canonical approval and does not perform that approval.
+
 ## Not yet addressed
 
 Certificate-failure-specific handling, permission-prompt-specific handling
 (Chromium's default deny-all applies; no permission is ever explicitly
 granted), and any non-loopback/remote browsing mode remain unimplemented and
-out of scope. `@dailephd/my-frontend-observer@0.9.0` is published to npm, and a
+out of scope. `@dailephd/my-frontend-observer@0.10.0` is the current release. A
 pre-release readiness CI workflow (Windows/Linux/macOS packed-candidate
 validation, now covering the v0.8 viewer alongside every earlier version's
 packed behavior) exists (see `docs/CI_CD.md`). The v0.7 external-reference/

package/docs/WORKFLOWS.md

@@ -685,11 +685,37 @@ repository. The run result's `status` must be `passed` and its
 `cleanupErrors` must be empty. The demo and scenarios are not in the npm
 package. See `examples/v09-demo/README.md` for details and maintenance notes.
 
-## Visual workflow progression (v0.9 implemented, v0.10 future)
+## Complete v0.10 visual-change workflow (implemented, unreleased)
 
 The sequence on top of the v0.7/v0.8 foundation above preserves the current
 engines and lets graphical interfaces consume rather than invent the reference
-model. v0.9 is released as `0.9.0`. v0.10 is still future:
+model. v0.9 is released as `0.9.0`; v0.10 is implemented in the repository
+and remains unreleased.
+
+Actual-frontend entry starts in project-aware `view`: open a runtime
+observation, draw and explicitly associate a mark, author and confirm runtime
+intent, save it, select confirmed intent, and create an inactive visual-change
+workflow. Reference entry opens one exact approved reference, saves confirmed
+reference intent against that instance, selects an exact baseline observation,
+authors explicit region-to-runtime bindings, and creates an inactive reference
+workflow.
+
+Both modes then share the same human-controlled loop:
+
+```text
+explicit Activate
+-> Prepare handoff
+-> external actor edits source outside Observer
+-> Run check (the canonical check <baseline> --json operation)
+-> immutable pending attempt
+-> Request correction, Accept latest PASS, or Abandon
+-> optional governance recording only after a separate canonical approval
+-> optional explicit Restore acceptance
+```
+
+The controlling invariants are `DRAW != DECIDE`, `CONFIRM !=
+PROMOTE/MATERIALIZE`, `PROMOTE/MATERIALIZE != ACTIVATE`, `PASS != ACCEPT`, and
+`ACCEPT != GOVERNANCE`.
 
 ```text
 stable targets and bounded runtime behavior
@@ -764,7 +790,7 @@ external-reference services.
 
 ## Current release workflow
 
-The published package is `@dailephd/my-frontend-observer@0.9.0`; install it
+The published package is `@dailephd/my-frontend-observer@0.9.1`; install it
 with npm and use the `my-frontend-observer` CLI. The ordinary workflow is
 `init`, `capture baseline`, `check baseline`, then `view`. Existing sections
 below retain the historical low-level and viewer workflows for compatibility.