@cassiomc1/forgeloop 0.1.6 → 0.1.9

package/AGENT_COMPATIBILITY.md

@@ -174,29 +174,41 @@ provider, remote service, or successful check.
 
 ## Installed files
 
-Every initialized project receives this guide plus the canonical documents:
+Every initialized project receives small native adapters at the project root
+and the canonical documents in the package-managed hidden kit. This keeps the
+root readable while preserving the standard instruction entry points:
 
 ```text
 AGENTS.md
 CLAUDE.md
-AGENT_COMPATIBILITY.md
-LOOP_ENGINEERING.md
-GUIDE_ROUTER.md
-PROJECT_PROFILE.md
-LOOP_SYSTEM_DESIGN.md
-QUALITY_SCORECARD.md
-TERMINOLOGY.md
-EXECUTION_STATE.md
-DELEGATION_PROTOCOL.md
-ORCHESTRATOR_INTEGRATION.md
-THIRD_PARTY_NOTICES.md
-LICENSE
-LICENSE-DOCS.md
 .cursor/rules/project-loop.mdc
 .github/copilot-instructions.md
-ENG/
-schemas/
+.forgeloop/manifest.json
+.forgeloop/current-contract.json
+.forgeloop/routing-result.json
+.forgeloop/work-state.json
+.forgeloop/kit/AGENT_COMPATIBILITY.md
+.forgeloop/kit/LOOP_ENGINEERING.md
+.forgeloop/kit/GUIDE_ROUTER.md
+.forgeloop/kit/PROJECT_PROFILE.md
+.forgeloop/kit/LOOP_SYSTEM_DESIGN.md
+.forgeloop/kit/QUALITY_SCORECARD.md
+.forgeloop/kit/TERMINOLOGY.md
+.forgeloop/kit/EXECUTION_STATE.md
+.forgeloop/kit/DELEGATION_PROTOCOL.md
+.forgeloop/kit/ORCHESTRATOR_INTEGRATION.md
+.forgeloop/kit/THIRD_PARTY_NOTICES.md
+.forgeloop/kit/LICENSE
+.forgeloop/kit/LICENSE-DOCS.md
+.forgeloop/kit/ENG/
+.forgeloop/kit/schemas/
 ```
 
+The package source retains the canonical root files so npm can ship and
+validate them; initialized targets use the hidden destination above. Existing
+legacy root files are not deleted when they are modified or unowned. Run
+`forgeloop update` to migrate unchanged managed files and review any reported
+conflict.
+
 See the main [README](https://github.com/cassiomc1/forgeloop#readme) for the complete `npx` installation,
 diagnostic, first-run, and update workflow.

package/ENG/taste-frontend-eng.md

@@ -0,0 +1,139 @@
+---
+name: taste-frontend-eng
+language: en
+description: "Contextual visual-taste review for premium frontend and brand-heavy work."
+version: "2026.09"
+last-reviewed: "2026-08-10"
+guide-id: taste
+---
+
+# Taste Skill for ForgeLoop Frontend Work
+
+This is a contextual review guide for premium marketing sites, landing pages,
+portfolios, brand surfaces, and high-finish redesigns. It is selected by the
+ForgeLoop router only when the work has that visual context. It is advisory: it
+does not create an approval gate, block an autonomous task, or require a
+specific framework, font, layout, animation library, or visual tool.
+
+The upstream inspiration is Taste Skill's design-read and anti-default
+approach. ForgeLoop keeps the useful review vocabulary while applying its own
+protocol boundaries: user evidence, accessibility, performance, security, and
+the active product constraints have priority over aesthetic preference.
+
+## Design Read
+
+Before editing, describe the existing or proposed system in observable terms:
+
+- What is the product promise, audience, and primary action?
+- Which visual idea creates recognition, and which elements are merely
+  decoration?
+- What are the current typography roles, color roles, spacing rhythm, grid,
+  image treatment, component shapes, and motion cues?
+- Where does the hierarchy break at the first viewport, on a narrow viewport,
+  or in a dense interaction state?
+
+Separate observed evidence from inference. If the implementation is not yet
+available, record the read as a hypothesis and keep it reversible.
+
+## Design Dials
+
+Use three lightweight dials to make an intentional decision rather than a
+generic default:
+
+- **Design variance:** familiar, distinctive, or experimental relative to the
+  product category.
+- **Motion intensity:** static, restrained, or expressive, limited by user
+  preference and runtime budget.
+- **Visual density:** quiet, balanced, or information-rich, tuned to the task
+  and reading conditions.
+
+Record the chosen direction in the design gate or contract assumptions when it
+materially changes implementation. Do not randomize values to manufacture
+novelty; deliberate variation should have a product or communication reason.
+
+## Anti-Slop Checks
+
+Review the whole page, not only the hero:
+
+- The first viewport states what the product is, for whom, and what to do.
+- Repeated sections have a reason and do not reuse one composition by habit.
+- The strongest contrast, scale, and whitespace support the intended hierarchy.
+- Decorative effects do not compete with content, controls, or error states.
+- Images, icons, testimonials, logos, metrics, and claims are real or clearly
+  marked as representative; never fabricate proof.
+- Framework, component, and template defaults are changed only when the
+  resulting system is more coherent and the change is justified.
+- Empty, loading, error, focus, hover, pressed, disabled, consent, and form
+  states belong to the same visual system.
+
+## Typography Quality
+
+Choose typography by role and reading need. Limit the number of families and
+weights to what the product needs, keep running text at a comfortable measure,
+and establish a clear display/body/metadata hierarchy. Verify the exact font
+source, license, loading cost, fallback, and language coverage before adding an
+external font. A distinctive type choice is optional; legibility and product
+evidence are not.
+
+## Layout Composition
+
+Build hierarchy from relationships: container, grid, alignment, rhythm,
+contrast, grouping, and breathing room. Vary section composition when that
+clarifies a narrative, but preserve predictable navigation and interaction.
+Use the smallest set of tokens that explains the system. Treat a deliberate
+asymmetry, quiet section, oversized statement, or dense data region as a
+decision to validate, not a rule to apply everywhere.
+
+## Motion Restraint
+
+Motion should explain change, guide attention, or provide feedback. Prefer
+short, interruptible, seek-safe transitions and respect
+`prefers-reduced-motion`, reduced-transparency preferences, focus, and input
+latency. A static implementation is valid when it communicates better or
+meets the performance budget. GSAP, scroll effects, canvas, WebGL, and shader
+effects are optional implementation choices, never universal requirements.
+
+## Responsive Composition
+
+Design narrow and wide compositions as related states, not as a desktop page
+scaled down. Re-check hierarchy, line length, touch targets, safe areas,
+navigation, image crops, overflow, and the primary action at the smallest
+supported viewport. Test intermediate widths when layout changes are likely;
+do not invent a breakpoint merely to match a visual convention.
+
+## Design-System Selection
+
+Use the existing product system when one is present. If the target has no
+system, choose a small coherent set of semantic tokens, components, states,
+and usage rules that the team can maintain. A vendor guide, gallery, template,
+or AI output can inform a direction, but it is not evidence of product fit,
+license, accessibility, or performance. Keep any external reference in the
+task's source and attribution records; do not add a network dependency to
+ForgeLoop runtime.
+
+## Visual Pre-Flight
+
+Before calling a visual task ready, check the smallest useful evidence set:
+
+- hierarchy and primary action at wide and narrow viewports;
+- keyboard focus, contrast, zoom, reduced motion, and semantic controls;
+- loading/error/empty/form states that are in scope;
+- image and font loading, console/runtime errors, and performance budget;
+- consistency of tokens, spacing, type roles, component states, and content
+  claims.
+
+If visual evidence is unavailable, record `NOT_VERIFIED` or a bounded
+limitation. Never turn an imagined screenshot or an unrun browser check into
+an observed result.
+
+## Redesign Audit
+
+For an existing interface, scan first and classify each issue as hierarchy,
+typography, color/contrast, composition, content, interaction, responsive
+behavior, accessibility, performance, or evidence. Fix the highest-leverage
+issues in small coherent batches. Re-read the whole system after each batch so
+local polish does not create a new inconsistency elsewhere.
+
+The final decision remains protocol-owned: this guide can recommend a visual
+change, but the contract, routing, gates, evidence, completion rules, and
+user-authorized constraints decide whether the task may proceed or close.

package/EXECUTION_STATE.md

@@ -7,8 +7,9 @@ Compatible agents may persist a handoff checkpoint at:
 ```
 
 The file is local, ignored by Git, schema-versioned, and never a replacement
-for the manifest or `PROJECT_PROFILE.md`. It contains no secrets and is
-untrusted on read.
+for the manifest or the target project profile (installed as
+`.forgeloop/kit/PROJECT_PROFILE.md`). It contains no secrets and is untrusted
+on read.
 
 ## Shape
 
@@ -69,17 +70,23 @@ An optional age threshold may recommend cheap verification with
 `CHECKPOINT_OLD` without changing a fresh result.
 
 `inspect`, `status`, and `validate-protocol` use the same derived freshness
-classifier. Protocol validation can be run against the complete artifact set:
+classifier. Protocol validation can be run against the current route, state,
+receipt, and contract artifacts:
 
 ```bash
 forgeloop validate-protocol \
-  --route-file ./routing-result.json \
+  --route-file .forgeloop/routing-result.json \
   --state-file .forgeloop/work-state.json \
-  --receipt-file ./execution-receipt.json \
+  --receipt-file .forgeloop/execution-receipt.json \
   --contract-file .forgeloop/current-contract.json \
   --json
 ```
 
+When delegation is in scope, repeat `--task-brief <path>` and
+`--delegated-result <path>` for the matching handoff artifacts. If those inputs
+are omitted, `validate-protocol` reports `INCOMPLETE` because delegation
+conformance was not supplied; this is distinct from a local `complete` result.
+
 `validate-protocol` reports `STALE` when the current repository fingerprint,
 contract, or required-artifact fingerprints require revalidation. Its JSON
 result exposes the comparison values, reasons, and warnings; the human output

package/GUIDE_ROUTER.md

@@ -47,6 +47,7 @@ project commands.
 | `test` | [Testing](./ENG/test-code-eng.md) | Risk-driven verification strategy and tooling |
 | `security` | [Security](./ENG/sec-code-eng.md) | Web, API, mobile, desktop, data, and supply-chain security |
 | `design` | [Design](./ENG/design-code-eng.md) | Visual direction, UX, motion, and perceived performance |
+| `taste` | [Taste frontend](./ENG/taste-frontend-eng.md) | Contextual design-read, anti-slop, and visual pre-flight for premium frontend work |
 | `performance` | [Performance](./ENG/perf-code-eng.md) | Measurement, diagnosis, budgets, and optimization |
 | `accessibility` | [Accessibility](./ENG/accessibility-eng.md) | WCAG, keyboard access, focus, semantics, and assistive technology |
 | `games` | [Web games](./ENG/games-code-design-web-eng.md) | Architecture and operation of 2D, 3D, and procedural web games |
@@ -153,6 +154,28 @@ rg -n '^## [0-9]+\.|brief|content|direction|design system|implementation|quality
 
 **Expected evidence:** approved strategy, content, direction, production, quality, launch, and operation gates.
 
+### `taste` — contextual frontend taste review
+
+**Activate when:** the router selects a premium marketing site, landing page,
+portfolio, brand-heavy surface, or high-finish redesign with a meaningful
+visual composition.
+
+**Do not activate when:** the task is backend, infrastructure, data, CLI,
+documentation, or a nonvisual bug. A UI word in a technical description is not
+enough context.
+
+Use this guide as an advisory review. It does not add a user-approval gate,
+require GSAP or a static-site approach, prescribe fonts/layouts, or override
+accessibility, performance, security, or product evidence.
+
+```bash
+rg -n '^## (Design Read|Design Dials|Anti-Slop Checks|Typography Quality|Layout Composition|Motion Restraint|Responsive Composition|Design-System Selection|Visual Pre-Flight|Redesign Audit)' ENG/taste-frontend-eng.md
+```
+
+**Expected evidence:** a contextual design read, intentional dials, bounded
+anti-slop review, and only the visual/accessibility/performance checks that are
+in scope. Mark unavailable visual evidence `NOT_VERIFIED`.
+
 ### `games` — web game architecture and operation
 
 **Activate when:** designing, implementing, testing, or operating a 2D or 3D web game, procedural generation, game loops, assets, input, multiplayer, or game distribution.
@@ -249,7 +272,7 @@ Route comments are stable contracts for the validator. They contain IDs, not loa
 
 ### Premium landing page
 
-<!-- route:landing-page-premium=premium,design,accessibility,clean,test,security,performance -->
+<!-- route:landing-page-premium=premium,design,taste,accessibility,clean,test,security,performance -->
 
 Verify the brief, content, responsive UI, states, WCAG coverage, build, tests, Web Vitals, forms, analytics, launch, and operation.
 

package/LOOP_ENGINEERING.md

@@ -286,6 +286,49 @@ forgeloop preflight
 
 `preflight` validates local ForgeLoop artifacts only. It does not invoke the model, run project commands, or treat a prose declaration as evidence. A `READY` result is required before `EXECUTING` in standard and strict workflows. A non-empty `current-contract.unresolvedDecisions[]` causes `forgeloop preflight` to return `BLOCKED` with `E_CONTRACT_UNRESOLVED_DECISION`; a valid `current-contract.assumptions[]` list does not block preparation.
 
+### Resumable activation and artifact reconciliation
+
+`PREFLIGHT_READY` is a durable checkpoint, not only a status value. A persisted
+READY result is valid only when the same target also contains:
+
+```text
+current-contract.json
+routing-result.json
+gates required by the route
+work-state.json
+events.ndjson with the activation chronology
+preflight.json with status READY
+```
+
+The activation event matrix is explicit:
+
+| Stage | Event | Requirement |
+| --- | --- | --- |
+| Task received | `TASK_RECEIVED` | New activation; one first event when the ledger is empty |
+| Contract validated | `CONTRACT_VALIDATED` | Before READY |
+| Route validated | `ROUTE_VALIDATED` | Before READY |
+| Gate satisfied | `GATE_SATISFIED` | One event for each satisfied required gate |
+| Preflight blocked | `PREFLIGHT_BLOCKED` | Persisted when activation is blocked |
+| Preflight ready | `PREFLIGHT_READY` | Exactly the matching READY fingerprints and gate sets |
+
+The ledger is append-only and hash-linked. A `BLOCKED → READY` recovery keeps
+the original `PREFLIGHT_BLOCKED` event, appends only newly satisfied gate and
+readiness events, and never deletes or rewrites history. `forgeloop next` is a
+read-only query: if READY remains but `work-state.json` is missing, it returns
+`RESOLVE_BLOCKER` with `E_STATE_MISSING_AFTER_PREFLIGHT_READY` instead of
+silently returning to discovery.
+
+`PROJECT_PROFILE.md` distinguishes planned template locations from files
+observed in the target. New targets receive canonical documents under
+`.forgeloop/kit/`; root `AGENTS.md`, `CLAUDE.md`, Cursor, and Copilot files are
+minimal native shims. `forgeloop update` migrates unchanged managed legacy root
+files, preserves modified or unowned files, and reports conflicts without
+following symlinks or escaping the selected target. Migration validates the
+complete plan, writes and verifies hidden destinations, atomically switches the
+manifest authority, and then cleans only legacy files whose recorded ownership
+hash still matches. `doctor` reports `E_MIGRATION_INCOMPLETE` for an interrupted
+authority switch or cleanup; a later `update` may safely resume that cleanup.
+
 ## Completion validation and chronology
 
 `COMPLETE` is a validator result, not a string an agent may assign by itself.
@@ -446,6 +489,7 @@ AUTHORITY_FAILURE
 ENVIRONMENT_FAILURE
 EXTERNAL_SERVICE_FAILURE
 STALE_STATE_FAILURE
+OPERATOR_INTERRUPTION
 ```
 
 For every failure, record the class, hypothesis, evidence, and next safe
@@ -479,6 +523,9 @@ The loop invariants are:
 21. protocol chronology must not permit execution before mandatory preflight events.
 22. publication status and production readiness must remain independent from local task completion.
 23. a task with implemented deliverables must not terminate in EXECUTING.
+24. a persisted PREFLIGHT_READY result must reconcile with a resumable state and
+    its matching append-only activation chronology.
+25. planned profile fields must not be reported as present target evidence.
 
 The serializable phase and transition contract is maintained in
 [`ORCHESTRATOR_INTEGRATION.md`](./ORCHESTRATOR_INTEGRATION.md). It is a host

package/LOOP_SYSTEM_DESIGN.md

@@ -22,6 +22,8 @@ The system should use every guide that materially helps the task without loading
 - The loop continues while safe progress is possible. Repetition without new evidence triggers hypothesis reassessment or a blocked result, not infinite retries.
 - Third-party provenance and reuse boundaries remain part of every portable copy.
 - Qwen-MM-Plugins is an optional, task-scoped capability extension: the agent checks native support first, installs the smallest missing capability when needed, and verifies it before use; it is not a package or runtime dependency.
+- Canonical documents are installed under `.forgeloop/kit/`; root native adapters remain small shims and mutable protocol artifacts remain directly under `.forgeloop/`.
+- `PREFLIGHT_READY` is a resumable protocol checkpoint reconciled with work state, activation events, fingerprints, and the append-only hash chain.
 
 ## Alternatives considered
 
@@ -46,33 +48,35 @@ the compatible harness.
 ```text
                             FORGELOOP
                                 │
-                  ┌─────────────┼─────────────┐
-                  │             │             │
-               ROUTING        STATE        EVIDENCE
-                  │             │             │
-                  ▼             ▼             ▼
-            deterministic   checkpoint    observable
-              decisions       facts         claims
-                  │             │             │
-                  │       ┌─────┴─────┐       │
-                  │       │           │       │
-                  │   repository   contract   │
-                  │       │           │       │
-                  │       └─────┬─────┘       │
-                  │             │             │
-                  │          freshness        │
-                  │             │             │
-                  └───────┬─────┴─────┬───────┘
-                          │           │
-                          ▼           ▼
-                    CONFORMANCE   DELEGATION
-                          │           │
-                          └─────┬─────┘
-                                ▼
-                    VALID / STALE / INVALID
-                                │
-                                ▼
-                        compatible harness
+                   ┌──────────────┼──────────────┐
+                   │              │              │
+                CONTRACT        ROUTE         EVIDENCE
+                   │              │              │
+                   └──────┬───────┴──────┬───────┘
+                          │              │
+                       required       current
+                        gates         fingerprints
+                          │              │
+                          ▼              │
+                      PREFLIGHT_READY   │
+                          │              │
+                   ┌──────┴──────┐       │
+                   │             │       │
+                work-state   event ledger │
+                   │             │       │
+                   └──────┬──────┘       │
+                          │              │
+                  plan → execute → verify → review
+                          │              │
+                          └──────┬───────┘
+                                 ▼
+                   AUDIT / COMPLETE / VALIDATE-PROTOCOL
+                                 │
+                                 ▼
+              VALID / INCOMPLETE / STALE / INCONSISTENT / INVALID
+                                 │
+                                 ▼
+                         compatible harness
 ```
 
 ```text
@@ -81,12 +85,14 @@ User request
     v
 Nearest agent adapter
     |
-    +--> LOOP_ENGINEERING.md
-    |        |
-    |        +--> PROJECT_PROFILE.md
-    |        +--> GUIDE_ROUTER.md
-    |                  |
-    |                  +--> ENG/*.md
+    +--> root native shim
+             |
+             +--> .forgeloop/kit/LOOP_ENGINEERING.md
+             |        |
+             |        +--> .forgeloop/kit/PROJECT_PROFILE.md
+             |        +--> .forgeloop/kit/GUIDE_ROUTER.md
+             |                  |
+             |                  +--> .forgeloop/kit/ENG/*.md
     |
     +--> repository-specific instructions
     |
@@ -188,7 +194,7 @@ Durable context for a destination project. The template captures:
 - constraints, decisions, and unverified items;
 - a source for every durable fact.
 
-The profile changes only when discovery reveals a real project change; it is not a task diary. In this source repository, `profile-mode: template` keeps it as a reusable template. After copying it into a code repository, the first cycle may change the mode to `project` and fill only confirmed facts.
+The profile changes only when discovery reveals a real project change; it is not a task diary. In this source repository, `profile-mode: template` keeps it as a reusable template. After `forgeloop init` installs it under `.forgeloop/kit/` in a target, the first cycle may change the mode to `project` and fill only confirmed facts.
 
 ### `DELEGATION_PROTOCOL.md`
 
@@ -212,7 +218,7 @@ mitigations, residual limitations, and executable evidence.
 
 ### `ENG/*.md`
 
-Eight canonical guides cover:
+Nine canonical guides cover:
 
 - clean code;
 - testing;
@@ -221,7 +227,8 @@ Eight canonical guides cover:
 - design;
 - accessibility;
 - premium website production;
-- web games.
+- web games;
+- contextual frontend taste.
 
 Each guide has exact English frontmatter and a stable guide ID.
 
@@ -328,7 +335,7 @@ The documentation workflow verifies:
 
 - every file referenced by an adapter exists;
 - repository-relative links resolve;
-- exactly eight canonical English guides exist;
+- exactly nine canonical English guides exist;
 - guide IDs, filenames, frontmatter keys, and `language: en` match the catalog;
 - no legacy language tree or bilingual metadata remains;
 - all route contracts contain valid guide IDs;
@@ -352,18 +359,12 @@ The validator also exercises six routing scenarios:
 The npm CLI installs the kit into the current directory or an existing
 directory selected with `--path` when the package is available in the npm
 registry. If it is not available yet, the same commands can run as
-`node src/cli.js ...` from a repository checkout. A user may also download the
-repository or a release archive and copy these items while preserving their
-relative structure:
-
-- the four native agent adapters plus `AGENT_COMPATIBILITY.md`;
-- the shared `AGENTS.md` entry point for the six compatible agents;
-- `LOOP_ENGINEERING.md`;
-- `GUIDE_ROUTER.md`;
-- `PROJECT_PROFILE.md`;
-- `THIRD_PARTY_NOTICES.md`;
-- `LICENSE` and `LICENSE-DOCS.md`;
-- the `ENG/` guide directory.
+`node src/cli.js ...` from a repository checkout. The CLI maps canonical
+documents into `.forgeloop/kit/`, keeps only native instruction shims at the
+target root, and leaves mutable contract, route, gate, state, event, preflight,
+and receipt artifacts under `.forgeloop/`. Manual copying must preserve that
+target layout; copying package-source root files directly is not equivalent to
+`forgeloop init`.
 
 The README explains the file set, activation behavior, current/relative/absolute
 target installation, first-run profile flow, local validation commands, and safe

package/PROJECT_PROFILE.md

@@ -10,6 +10,19 @@ last-confirmed: unknown
 > Durable context for [Loop Engineering](./LOOP_ENGINEERING.md). Fill it only
 > with evidence from the target project.
 
+This source profile is a template. Its planned fields describe what a target
+may confirm after bootstrap; they do not assert that the corresponding product
+files, services, commands, or directories are present in the source kit.
+
+Use these terms precisely:
+
+- **Planned**: an expected discovery field or protocol location, not observed
+  product evidence.
+- **Present**: observed in the target with a file, command, manifest, or other
+  authoritative source.
+- **Absent**: checked and not found; record the check and scope.
+- **Unverified**: not checked yet; do not infer presence from this template.
+
 ## Maintenance rules
 
 - Update a fact only after inspecting authoritative files, commands, or sources.
@@ -21,18 +34,18 @@ last-confirmed: unknown
 - Keep `language: en`; this kit has no alternate language variant.
 - Do not use this file as a task diary.
 
-## Product and objective
+## Product and objective (planned vs observed)
 
-| Field | Current state | Source |
+| Field | Planned baseline or observed state | Source |
 | --- | --- | --- |
 | Product | Not identified — confirm from the stated source | Source not identified |
 | Users | Not identified — confirm from the stated source | Source not identified |
 | Primary outcome | Not identified — confirm from the stated source | Source not identified |
 | Durable exclusions | Not identified — confirm from the stated source | Source not identified |
 
-## Confirmed stack
+## Confirmed stack (planned vs observed)
 
-| Layer | Technology and version | Source |
+| Layer | Planned baseline or observed technology and version | Source |
 | --- | --- | --- |
 | Frontend | Not identified — confirm from the stated source | Source not identified |
 | Backend | Not identified — confirm from the stated source | Source not identified |
@@ -44,9 +57,9 @@ last-confirmed: unknown
 Record a missing manifest or configuration as verified absence. Do not infer a
 stack from technology names found only in documentation or examples.
 
-## Official commands
+## Official commands (planned vs observed)
 
-| Purpose | Confirmed command | Source |
+| Purpose | Planned baseline or observed command | Source |
 | --- | --- | --- |
 | Installation | Not identified — confirm from the stated source | Source not identified |
 | Development | Not identified — confirm from the stated source | Source not identified |
@@ -60,9 +73,9 @@ stack from technology names found only in documentation or examples.
 Never invent a command when the project already declares official scripts or
 automation.
 
-## Architecture and directories
+## Architecture and directories (planned vs observed)
 
-| Area | Path or responsibility | Source |
+| Area | Planned location or observed responsibility | Source |
 | --- | --- | --- |
 | Primary entry point | Not identified — confirm from the stated source | Source not identified |
 | Domain | Not identified — confirm from the stated source | Source not identified |
@@ -72,7 +85,7 @@ automation.
 | Documentation | Not identified — confirm from the stated source | Source not identified |
 | CI/CD | Not identified — confirm from the stated source | Source not identified |
 
-## Supported platforms
+## Supported platforms (planned vs observed)
 
 | Surface | Confirmed targets | Evidence |
 | --- | --- | --- |
@@ -82,7 +95,7 @@ automation.
 | Browsers and devices | Not identified — confirm from the stated source | Source not identified |
 | Accessibility requirements | Not identified — confirm from the stated source | Source not identified |
 
-## Services and risk surfaces
+## Services and risk surfaces (planned vs observed)
 
 | Item | Use and risk | Safe source |
 | --- | --- | --- |
@@ -97,7 +110,7 @@ automation.
 Record only the mechanism and safe configuration location. Never copy credential
 values.
 
-## Constraints and decisions
+## Constraints and decisions (planned vs observed)
 
 | Decision or constraint | State | Source |
 | --- | --- | --- |
@@ -121,4 +134,6 @@ appropriate section.
 | Not identified | Not identified — confirm from the stated source | Source not identified | Not identified |
 
 Keep evidence concise. Long outputs, temporary logs, and per-task history do not
-belong in this file.
+belong in this file. A planned row becomes present only after the target check;
+an absent row must include the scope of the check rather than being silently
+treated as a missing product feature.

package/QUALITY_SCORECARD.md

@@ -23,6 +23,10 @@ policy are all present.
 | Autonomous-mode precedence — structural | Explicit `autonomousMode=true` boundary, explicit interactive opt-in, preservation of `NON_BLOCKING`, and no silent workflow-induced mode switch. |
 | Pre-contract autonomy — cross-agent live robustness | Independent live-agent behavior across fresh package installs, exact blind prompts, one-process/no-subagent topology, and separate evidence for non-blocking continuation versus blocking clarification. Structural coverage does not imply live cross-agent robustness. |
 | Resume/checkpoint | Atomic local state, contract/HEAD/artifact freshness, age warning, schema/secret validation, status, safe validation, and bounded clearing without persisting derived freshness fields. |
+| Protocol activation resumability | `PREFLIGHT_READY` durably creates or reconciles `work-state.json`, preserves blocked history, and exposes a dedicated repair code when the checkpoint is missing. |
+| Artifact ↔ lifecycle reconciliation | Contract, route, gates, state, preflight, activation events, fingerprints, and append-only hash chronology agree at READY; audit and validate-protocol detect divergence. |
+| Planned vs present profile truth | `PROJECT_PROFILE.md` distinguishes planned template fields from observed target facts, with hidden-kit bootstrap and legacy migration checks. |
+| Contextual frontend taste | Taste is routed only to applicable premium frontend work, remains advisory, respects accessibility/performance/evidence, and has attribution without runtime dependency. |
 | Multi-agent coordination | Self-contained briefs, write/write and write/read ownership checks, dependency-set validation, reviewer independence, normalized results, and inline fallback. |
 | Security boundaries | Realpath containment, bounded untrusted JSON, threat model, nested secret scanning, publication evidence, and explicit authority rules. |
 | Maintenance quality | Small modules, built-in runtime, deterministic JSON contracts, malformed/version fixtures, package gates, and backward-compatible protocol versions. |
@@ -72,6 +76,9 @@ are both present:
 | Security boundary | realpath containment, bounded JSON, `THREAT_MODEL.md`, secret-free artifacts, authority and no-runtime rules | `tests/security-limits.test.js`, Markdown/loop validators, and `scripts/scan_secrets.py` |
 | Cross-artifact conformance | `src/core/conformance.js`, `classifyLoadedWorkState`, and `forgeloop validate-protocol --contract-file` | `tests/conformance.test.js`, `tests/validate-protocol-cli.test.js`, and protocol fixtures covering precedence and stale evidence |
 | Protocol preparation and completion | `src/core/preflight.js`, `src/core/completion.js`, `src/core/events.js`, policy packs, and portable bundles | `tests/preflight.test.js`, `tests/completion.test.js`, `tests/lifecycle.test.js`, `tests/policy.test.js`, and `tests/bundle.test.js` |
+| Protocol activation resumability | `src/core/resumability.js`, READY consistency checks, event matrix, and `next` repair semantics | `tests/resumable-protocol.test.js` |
+| Hidden kit layout | `src/core/target-layout.js`, safe init/update migration, manifest layout version, native shims, and profile resolver | `tests/hidden-layout.test.js`, package and compatibility tests |
+| Contextual frontend taste | `ENG/taste-frontend-eng.md`, router metadata, attribution, and design/accessibility precedence | `tests/taste-guide.test.js`, route fixtures |
 | Pre-contract autonomy — structural | `LOOP_ENGINEERING.md`, `src/core/decision-classification.js`, `src/core/workflow-compatibility.js`, `CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`, `.cursor/rules/project-loop.mdc` | `tests/decision-classification.test.js`, `tests/workflow-compatibility.test.js`, `tests/autonomy-policy.test.js`, `tests/preflight.test.js` |
 | External workflow compatibility — structural | `LOOP_ENGINEERING.md`, `AGENT_COMPATIBILITY.md`, `src/core/workflow-compatibility.js`, and sixth-run harness metadata rule | `tests/workflow-compatibility.test.js`, `conformance/README.md` |
 | Instruction-conflict handling — structural | Canonical source-attribution and `WORKFLOW_CONFLICT` policy in `LOOP_ENGINEERING.md` plus adapter references | `tests/autonomy-policy.test.js`, `tests/workflow-compatibility.test.js` |