website-build-skill 0.1.3 → 0.1.5

package/skills/website-build-skill/prompts/12-web-design-team.md

@@ -4,6 +4,7 @@ Never ask the user for the date or infer it from model knowledge. Apply the
 same source, two-date, freshness, reuse, and blocked-gate rules to this stage.
 
 Run option 2, Give me the team, using the human's recorded install choice.
+TEAM: one command installs the seven workers' files; you open each session yourself and carry the handoffs between them. Researcher goes first.
 Needs Claude Code, Codex, Hermes, Antigravity, or Grok Bot. Follow the setup line for that host.
 
 Every agent runs its own research pass before it touches your site, so it works from what is
@@ -16,27 +17,26 @@ SET UP
 - Read roles/researcher.md first, then roles/coordinator.md, roles/designer.md,
   roles/graphics.md, roles/builder.md, roles/optimizer.md, roles/reviewer.md,
   and templates/handoff.yaml. Use each complete body, not these short summaries.
-- Create or identify Website Researcher first, then Website Coordinator,
+- The human opens Website Researcher first, then Website Coordinator,
   Website Designer, Website Graphics, Website Builder, Website Optimizer, and
-  Website Reviewer as separate sessions, Bots, or terminals. Parent may coordinate
-  only after the research gate. Use supported setup mechanisms, not invented imports.
-- Installer or human checks routes and obtains seven setup acknowledgements.
+  Website Reviewer as separate sessions, Bots, or terminals. Coordinator works
+  only after the research gate. Use available session controls and complete role files.
+- The human checks each session reference and obtains seven setup acknowledgements.
   These confirm receipt of instructions, not permission to start downstream work.
 - A role label in one conversation is option 1. Record SOLO and use prompts/00-start.md
   if separate workers cannot be reached. A same-family team remains a team but
   cannot pass independent review. Respect host concurrency limits.
-- Antigravity setup uses generated agent definitions and per-role tool declarations;
-  Hermes setup uses the verified definition branch or generated session packets and
-  bundle alias. Read the host adapter and receipt; pending discovery, trust, tools,
-  or independent review checks cannot be reported as a ready team.
+- Read the host adapter and receipt. The installer supplies role files and bundles;
+  the human opens sessions, checks trust and tools, and supplies each worker's files.
+  Pending discovery, trust, tools or independent review checks remain explicit limits.
 - Supply the request, authorized workspace, source assets, and tools to Researcher.
-  All other roles wait. Use the manual fallback in the team bundle if setup cannot
-  be automated; actual package integration remains UNVERIFIED until tested.
+  All other roles wait. Carry the complete packets using the manual setup below;
+  actual host loading remains UNVERIFIED until tested.
 
 RESEARCHER
 - Own site-work/research/library/ and handoffs/researcher/; own both research resources.
 - Run prompts/01-website-deep-research.md, with the inactive graphics original as
-  provenance. Complete all thirteen domains and their checklists current as of the ASK DATE.
+  provenance. Complete all fourteen domains and their checklists current as of the ASK DATE.
 - Save the library before any other role works. Gate: the library exists on disk,
   every domain this project touches has a substantive file and checklist, and every
   acted-on claim has an opened source URL, a publication/update date or explicit unknown, and an access date on or after the ASK DATE. UNVERIFIED cannot pass a claim.
@@ -67,7 +67,9 @@ GRAPHICS
 
 BUILDER
 - After mockup selection, learn codebase/stack, accessibility/performance and
-  security/delivery research; top up chosen APIs, headers, and measurement rules.
+  security/delivery and language/coding research; top up chosen APIs, headers, and measurement rules.
+- After Choose and before Build, run prompts/13-coding-research.md and read
+  site-work/coding-standards.md; apply checklists/code-quality.md to the implementation.
 - Own stack choice, implementation, performance, headers, build evidence and release.
 - Integrate Graphics and Optimizer outputs without editing their original sources.
 - Prepare the immutable candidate/audit brief; reproduce findings and test fixes.
@@ -83,6 +85,7 @@ REVIEWER
 - Last before ship, use a different model family or return INTERNAL, gate BLOCKED.
 - Learn the relevant library and top up current attack, accessibility and scanner facts.
 - Review the fixed candidate read-only; return findings and research without edits.
+- Check code against site-work/coding-standards.md and checklists/code-quality.md.
 - Return reproducible evidence or an explicit scoped no-findings result.
 - Apply checklists/ship.md ASK DATE checks to library and top-ups; reject undated,
   stale-access and stamped-but-unrevalidated claims as findings.
@@ -111,9 +114,9 @@ Never report a measured, saved, installed, or deployed result without evidence.
 Apply checklists/research.md before downstream dispatch and checklists/ship.md before release.
 
 PORTABLE MANUAL SETUP
-Use this fallback when native adapters or generated bundles are not supplied.
-Native loading, automatic worker creation, routing, tool enforcement and different-family
-availability are UNVERIFIED until the actual host/session checks succeed.
+Use this setup for TEAM on every host. You open each session and carry every handoff.
+Host loading, file access, tool enforcement and different-family availability remain
+UNVERIFIED until the actual host/session checks succeed.
 A missing host adapter does not authorize inventing a native file format or import API.
 
 1. Open the host's verified worker/session creation surface, if available.
@@ -125,8 +128,8 @@ A missing host adapter does not authorize inventing a native file format or impo
    with evidence, tools, inaccessible files, and owned paths. Keep downstream work pending.
 5. Give Reviewer a read-only candidate packet or verified read-only session. Broad
    inherited tools do not become restricted because role prose says read-only.
-6. Verify a bounded setup message reaches each intended route through supported controls.
-   When group automation is absent, the human can relay addressed packets and attachments.
+6. Deliver a bounded setup message to each session yourself. Relay addressed packets
+   and attachments, and verify each receiving worker can open them.
 7. Give the user's actual request, authorized workspace, assets and constraints to
    Researcher alone. It establishes ASK DATE and completes the library and gate first.
 8. Relay its complete passing receipt and readable library to Coordinator. Coordinator
@@ -135,7 +138,7 @@ A missing host adapter does not authorize inventing a native file format or impo
 Preserve seven acknowledgements separately from research and work-readiness receipts.
 A text-only group requires direct image attachments to each receiving visual reviewer.
 Inaccessible files or routes keep the relevant handoff BLOCKED.
-No automatic creation support means a manual setup limit, not a claimed ready team.
+Completed file installation means the files are available; session setup is the human's next step.
 No separate workers means SOLO; no independent family means independent review BLOCKED.
 Never invent a platform capability to fill a setup gap.
 

package/skills/website-build-skill/prompts/13-coding-research.md

@@ -0,0 +1,83 @@
+ASK DATE prerequisite: follow playbooks/research-and-memory.md#ask-date-rule.
+Researcher establishes it before intake or research; later roles read scope.md.
+Never ask the user for the date or infer it from model knowledge. Apply the
+same source, two-date, freshness, reuse, and blocked-gate rules to this stage.
+
+Research how to code this project's selected stack before writing website code.
+Run as Builder after CHOOSE in [prompts/05-stack-and-build.md](05-stack-and-build.md)
+and before IMPLEMENT. Require accepted research, a named mockup selection, and
+site-work/stack.md with the selected stack and exact versions.
+
+LEARN
+- Read site-work/research/library/README.md, scope.md, coverage.md, sources.md,
+  staleness.md, 08-languages-and-code.md, and checklists/14-code.md.
+- Read the approved brief, browser targets, host constraints, and stack.md.
+  Top up the chosen path and its unresolved questions against the saved library.
+- Return stale or wrong library claims to Researcher with claim IDs and evidence;
+  resume affected decisions after a corrected library receipt.
+
+RESEARCH
+- Open primary sources as of the ASK DATE: MDN, web.dev Baseline status, WHATWG
+  and W3C specifications, TC39 finished proposals, TypeScript release notes, and
+  the selected runtime, framework, package manager, and tools' official docs,
+  changelogs, upgrade guides, and security advisories.
+- Verify the exact selected language targets, runtime and framework versions,
+  supported combinations, module format, and build or bundling defaults. For
+  living standards, record the dated specification and browser targets; for an
+  absent runtime, compiler, or framework, record NOT APPLICABLE with a reason.
+- Research current HTML semantics and elements; CSS layout, container queries,
+  cascade layers, and nesting; and JavaScript/TypeScript features for this stack.
+  Record each proposed feature's Baseline or target browser/runtime support and
+  the fallback or exclusion when support misses the project's targets. For
+  compiler-only features, mark Baseline NOT APPLICABLE and cite compiler support.
+  Verify implementation support separately from a proposal being finished.
+- Identify the selected framework version's idioms, deprecated APIs, replacement
+  patterns, and upgrade notes. Map organization rules to this project's routes,
+  components, data, rendering, tests, and generated output.
+- Select unit, integration, and end-to-end checks for the actual failure modes.
+  Verify lint, format, and type-check tools and commands for the pinned versions.
+  Give any inapplicable test level or tool a project-specific reason.
+- Define dependency hygiene: justify each dependency, pin direct versions and
+  toolchain versions, preserve the lockfile, use reproducible install commands,
+  audit advisories, and record findings, owners, and update/recheck decisions.
+- Research secure template and script handling for the actual stack: structural
+  escaping by output context, script-safe serialization, URL scheme validation,
+  input validation, and secrets supplied through the server-side environment.
+  Keep secrets out of inline scripts, client bundles, source, and recorded output.
+- For every dated claim, save the opened URL, publication/update date or unknown,
+  actual access date, and supporting evidence under site-work/research/builder/.
+  Record fetched-page receipts when opening sources using templates/evidence.md.
+  Keep disagreements and unresolved claims explicit. Apply the canonical freshness
+  windows and later-day rechecks before using a claim.
+
+SAVE AND INGEST
+Write site-work/coding-standards.md, opening with "Research as of <ASK DATE>".
+Include these sections:
+1. Pinned language, runtime, framework, and tooling versions or dated targets,
+   with source URLs, source dates, access dates, and relevant claim IDs.
+2. Features to use, each with Baseline or target support status and any fallback.
+3. Deprecated APIs and patterns to avoid, with their supported replacements.
+4. Project commands for unit, integration, and end-to-end tests, linting,
+   formatting, and type-checking, including working directory and prerequisites.
+   Label commands PLANNED until executed; link actual command output after Build.
+5. Dependency policy, lockfile and pinning rules, install/audit commands, advisory
+   handling, and the reason each dependency is needed.
+6. Secure-coding rules for this stack, with concrete adverse cases to verify.
+7. Code organization rules and a short code-review checklist tied to these choices.
+
+Reopen the standards file and record its revision, learned rules, and applied
+claim/check IDs in site-work/research/builder/learning.md before implementation.
+Use [checklists/code-quality.md](../checklists/code-quality.md) during Build and
+include its receipts and the standards file in the Reviewer packet. Revalidate
+affected standards when selected versions, requirements, or source freshness change.
+
+BLOCKED RESEARCH
+If search or source access is unavailable, follow playbooks/research-and-memory.md:
+return a query plan and unresolved-claim ledger for the selected stack, keep research
+BLOCKED, and stop before implementation. Training memory or a previous library
+does not pass current research. If file writing is unavailable, return named file
+bodies for saving and read-back before the standards gate can pass.
+
+EVIDENCE
+Never report a measured, saved, installed, or deployed result without evidence.
+Apply the stage route and named checks in manifest.json before handing off.

package/skills/website-build-skill/roles/builder.md

@@ -4,7 +4,7 @@ You are Website Builder, accountable for implementation, performance, headers, a
 
 ## WHAT YOU OWN
 
-Write site-work/stack.md, build/, qa/build/, qa/site-audit.md,
+Write site-work/stack.md, coding-standards.md, build/, qa/build/, qa/site-audit.md,
 qa/accessibility.md, qa/contrast.md, qa/security-headers.md, audit/, release/,
 research/builder/, and handoffs/builder/. Own the authorized implementation_root
 recorded in site-work/ownership.yaml and its SITE_OPERATIONS.md. Only you materialize
@@ -31,18 +31,22 @@ disagreements.md, unresolved-claims.md, and staleness.md in that same directory.
 Verify the research gate and current revision before doing your job. Then read
 site-work/research/library/01-codebases-and-stacks.md,
 04-accessibility-and-performance.md, 06-security-and-delivery.md,
-07-measurement-and-operations.md, and 05-search-and-answers.md for integration.
+07-measurement-and-operations.md, 08-languages-and-code.md, and
+05-search-and-answers.md for integration.
 Apply library checklists/01-codebases.md, 02-stacks.md, 05-ui-ux.md,
-06-accessibility.md, 07-performance.md, 10-security.md, and 11-hosting.md.
+06-accessibility.md, 07-performance.md, 10-security.md, 11-hosting.md, and 14-code.md.
 Learn the smallest-stack decision from playbooks/choose-stack.md and
 references/stacks/static-html.md, scripted-static.md, and framework.md.
 Read site-work/research/library/recipes.md for build and asset commands already proven here,
 and append the ones you get working.
 Read playbooks/data-and-templates.md, image-pipeline.md, self-hosted-fonts.md,
 embed-facades.md, security-headers.md, performance-budgets.md, accessibility.md,
-and deploy-and-operate.md. Read checklists/build.md, accessibility.md, security.md,
-ship.md; prompts/05-stack-and-build.md, 09-security-headers.md,
-10-adversarial-pre-ship.md, 11-ship-and-verify.md; templates/audit-brief.md.
+and deploy-and-operate.md. Read checklists/build.md, code-quality.md,
+accessibility.md, security.md, ship.md; prompts/05-stack-and-build.md, 09-security-headers.md,
+10-adversarial-pre-ship.md, 11-ship-and-verify.md, 13-coding-research.md;
+templates/audit-brief.md. After choosing the stack, run prompts/13-coding-research.md,
+then read and ingest site-work/coding-standards.md before writing code. Record the
+standards revision and learned rules in research/builder/learning.md.
 Record the checklist IDs and research decisions used before coding.
 
 ## WHAT YOU MUST RESEARCH
@@ -95,7 +99,8 @@ For release, require release-to-builder with authority and final gate receipts.
 
 ## YOUR OUTPUTS
 
-Produce stack.md with alternatives and requirement mapping; source and generated
+Produce stack.md with alternatives and requirement mapping; coding-standards.md
+with current selected-stack rules and source evidence; source and generated
 artifact at implementation_root; reproducible build/tests, QA evidence, response
 headers, audit/AUDIT_BRIEF.md with ROUND 1 dispositions, release receipt/rollback
 identity, and SITE_OPERATIONS.md. Name what watches the site, including nothing.
@@ -106,8 +111,9 @@ learned rules, source IDs, and applied checks. A proposal is not a completed sav
 
 ## YOUR GATE
 
-Before coding, require selected mockup plus current sourced research. Validate
-fallible data, context-specific escaping, script terminators, URL schemes, empty IDs,
+Before coding, require selected mockup, current sourced research, and saved/read-back
+coding-standards.md. Apply checklists/code-quality.md to the candidate before handoff.
+Validate fallible data, context-specific escaping, script terminators, URL schemes, empty IDs,
 and shared state. Prove the next repeated page is a data change. Run relevant
 accessibility, performance, discovery and header checks on rendered output.
 Use the current library's standards and the declared package defaults separately.

package/skills/website-build-skill/roles/coordinator.md

@@ -33,12 +33,13 @@ Verify the research gate and current revision before doing your job. Then read
 site-work/research/library/01-codebases-and-stacks.md,
 02-design-and-experience.md, 03-graphics-and-rights.md,
 04-accessibility-and-performance.md, 05-search-and-answers.md,
-06-security-and-delivery.md, and 07-measurement-and-operations.md in that directory.
+06-security-and-delivery.md, 07-measurement-and-operations.md, and
+08-languages-and-code.md in that directory.
 Learn stage acceptance from SKILL.md, prompts/00-start.md,
 prompts/12-web-design-team.md, playbooks/research-and-memory.md,
 playbooks/deploy-and-operate.md, checklists/research.md, checklists/ship.md,
 templates/brief.md, templates/status.md, and templates/handoff.yaml.
-Open all thirteen library checklists and assign an accountable downstream owner.
+Open all fourteen library checklists and assign an accountable downstream owner.
 Record learned rules and applied checklist evidence in your learning receipts.
 
 ## WHAT YOU MUST RESEARCH

package/skills/website-build-skill/roles/researcher.md

@@ -97,12 +97,12 @@ Use Markdown for research outputs; record actual access dates and source dates
 separately. Unknown publication dates stay unknown, never invented.
 
 Use [the research prompt](../prompts/01-website-deep-research.md) as the single
-source for the thirteen-domain questions, output filenames and applicability rules.
+source for the fourteen-domain questions, output filenames and applicability rules.
 Read it before starting; survey each domain and preserve explicit exclusions with reasons.
 Expand relevant questions for the actual brief rather than treating the list as a ceiling.
 
 Use [the canonical freshness rule](../playbooks/research-and-memory.md#ask-date-rule)
-for the thirteen-domain table, date arithmetic, current-version triggers, same-day checks
+for the fourteen-domain table, date arithmetic, current-version triggers, same-day checks
 and prior-library pass. Copy that table into the project's staleness.md, with claim-level
 revalidation and the earliest-expiring domain. Never maintain a separate policy table here.
 
@@ -128,20 +128,21 @@ resolve the canonical record; never silently erase an earlier disagreement.
 
 ## YOUR OUTPUTS
 
-Write seven grouped Markdown files: 01-codebases-and-stacks.md,
+Write eight grouped Markdown files: 01-codebases-and-stacks.md,
 02-design-and-experience.md, 03-graphics-and-rights.md,
 04-accessibility-and-performance.md, 05-search-and-answers.md,
-06-security-and-delivery.md, and 07-measurement-and-operations.md under your library.
+06-security-and-delivery.md, 07-measurement-and-operations.md, and
+08-languages-and-code.md under your library.
 Write README.md with headline findings and each role's reading order; scope.md and
-coverage.md mapping all thirteen domains to files, checklists, applicability, and
+coverage.md mapping all fourteen domains to files, checklists, applicability, and
 blockers; sources.md with stable claim IDs, URLs, source/access dates, and scope;
 disagreements.md, query-plan.md, and unresolved-claims.md with next verification steps.
-Write all thirteen checklists named in the domains, using criterion, method,
+Write all fourteen checklists named in the domains, using criterion, method,
 expected evidence, source IDs, owner, status, and exclusion reason per check.
 Write website-qa-checklist.md and how-to-read-a-brand-kit.md so research is executable.
 Write surprises.md as a short sourced summary for the user, and learning.md as your
 record of learned rules. Every research output is Markdown with the dated opener.
-Write staleness.md with the canonical playbook's thirteen-domain table, claim/domain, ASK DATE,
+Write staleness.md with the canonical playbook's fourteen-domain table, claim/domain, ASK DATE,
 window, original access, last revalidation, next-check date, trigger, reason, owner,
 affected receipts, and the earliest-expiring domain and its ASK DATE-relative due date. Recheck volatile pricing,
 rights, APIs, host rules, and crawler/search claims on the day they will be used.
@@ -172,7 +173,7 @@ your self-check must cover the same evidence without claiming independent review
   backed by actual current source access. Do not restamp unrevalidated content.
 - No search means BLOCKED with query-plan.md and unresolved-claims.md, including
   for an existing library. Never ask the user for the date to clear a failed rung.
-All thirteen domains have an explicit disposition; a blank section is not coverage.
+All fourteen domains have an explicit disposition; a blank section is not coverage.
 Every relied-on disagreement is resolved by evidence or blocks the dependent choice.
 UNVERIFIED claims remain visible but cannot authorize work. Missing sources, dates,
 coverage, expired relied-on facts, or unsaved files mean BLOCKED, not qualified PASS.

package/skills/website-build-skill/roles/reviewer.md

@@ -32,12 +32,14 @@ disagreements.md, unresolved-claims.md, and staleness.md in that same directory.
 Verify the research gate and current revision before doing your job. Then read
 site-work/research/library/01-codebases-and-stacks.md,
 04-accessibility-and-performance.md, 05-search-and-answers.md,
-06-security-and-delivery.md, and 03-graphics-and-rights.md for rights checks.
+06-security-and-delivery.md, 08-languages-and-code.md, and
+03-graphics-and-rights.md for rights checks. Read site-work/coding-standards.md.
 Read all applicable library checklists, especially 06-accessibility.md,
-10-security.md and 13-legal.md. Read prompts/10-adversarial-pre-ship.md,
+10-security.md, 13-legal.md, and 14-code.md. Read prompts/10-adversarial-pre-ship.md,
 playbooks/data-and-templates.md, playbooks/security-headers.md,
-playbooks/accessibility.md, checklists/build.md, checklists/accessibility.md,
-checklists/security.md, checklists/ship.md, and templates/audit-brief.md.
+playbooks/accessibility.md, checklists/build.md, checklists/code-quality.md,
+checklists/accessibility.md, checklists/security.md, checklists/ship.md,
+and templates/audit-brief.md.
 Return your learning receipt with opened files, assumptions challenged, and checks.
 
 ## WHAT YOU MUST RESEARCH
@@ -108,6 +110,9 @@ Old dates may appear only as explicit history alongside current validated access
 Treat a confident undated claim as a finding, not a detail. Verify source dates,
 ladder provenance, due domains and later-day rechecks; return violations read-only.
 Check actual different-family evidence and the precise artifact reviewed. Challenge
+the code against checklists/code-quality.md and site-work/coding-standards.md,
+including pinned versions, deprecated APIs, support, commands, dependencies, secure
+coding, organization, and Builder's code-review evidence. Challenge
 input/URL/script escaping, empty IDs, shared state, auth and secrets where applicable,
 headers, rendered discovery, accessibility journeys, and assumptions in the brief.
 Return enough evidence for Builder to reproduce each asserted defect; otherwise

package/skills/website-build-skill/templates/evidence.md

@@ -16,7 +16,7 @@ Record the scope link, library revision, engagement identifier, producer role an
 | Field | Required value and evidence |
 | --- | --- |
 | claim_id | Stable identifier referenced by decisions, checks and findings. |
-| domain | One of the thirteen research domains, with additional scoped concerns as needed. |
+| domain | One of the fourteen research domains, with additional scoped concerns as needed. |
 | statement | Exact bounded claim, including relevant version, tier, consumer or use. |
 | kind | Evidence, inference, proposed default, measurement, or UNVERIFIED. |
 | source_url | Opened authoritative URL; a search snippet does not satisfy this field. |

package/src/bundle.mjs

@@ -140,6 +140,7 @@ export function generated(root) {
   index += '- [Installer](docs/INSTALLER.md): headless setup, destinations, receipts, exit codes and uninstall\n';
   index += '- [Compatibility](docs/COMPATIBILITY.md): host setup routes and the evidence for each\n';
   index += '- [Documentation](docs/README.md): method, tips, provenance and evaluation\n\n';
+  index += "TEAM: one command installs the seven workers' files; you open each session yourself and carry the handoffs between them. Researcher goes first.\n\n";
   index += '## Active sources\n\n';
   for (const asset of m.assets.filter(a => a.active)) index += `- [${asset.path}](${CORE}/${asset.path}): ${describe(root, asset)}\n`;
   index += '\n## Bundles\n\n';

package/src/install.mjs

@@ -1,5 +1,5 @@
 import fs from 'node:fs';
-import { resolve, relative, dirname, basename, sep } from 'node:path';
+import { resolve, relative, dirname, basename, join, sep } from 'node:path';
 import { fileURLToPath } from 'node:url';
 import { randomUUID } from 'node:crypto';
 import { CORE, files, owned, digest } from './bundle.mjs';
@@ -59,6 +59,22 @@ export function safePath(root, name) {
 const receiptName = '.website-build-skill-receipt.json';
 const result = (code, message) => ({ code, message });
 
+function canonicalReceipt(path, root, destination, outputRoot) {
+  const boundaries = [destination, outputRoot].filter(Boolean);
+  // Resolve the user's root spelling, but inspect its suffix before using the canonical
+  // receipt parent: otherwise a planted link below an output or destination root disappears.
+  // An ancestor that resolves anywhere INSIDE a root (an alias to a subdirectory, not only
+  // to the root itself) is walked from that root, so no link below it is skipped.
+  for (let parent = dirname(path); ; parent = dirname(parent)) {
+    const base = canonical(parent);
+    for (const boundary of boundaries) {
+      if (inside(boundary, base)) safePath(boundary, join(relative(boundary, base), relative(parent, path)));
+    }
+    if (dirname(parent) === parent) break;
+  }
+  return safePath(root, resolve(root, basename(path)));
+}
+
 function validate(request) {
   if (!Object.hasOwn(targets, request.target)) throw Error('Unknown or missing target');
   if (!['solo', 'team'].includes(request.mode)) throw Error('Mode must be solo or team');
@@ -240,11 +256,12 @@ export function install(request = {}) {
       destination = resolve(project, targets[request.target]);
       receiptPath = resolve(request.receipt ?? resolve(destination, receiptName));
       receiptRoot = request.receipt ? canonical(dirname(receiptPath)) : destination;
-      outputRoot = request.outputDir === undefined ? null : canonical(request.outputDir);
     }
+    outputRoot = request.outputDir === undefined ? null : canonical(request.outputDir);
   } catch (error) { return result(2, error.message); }
-  if (request.uninstall) return uninstall(request, destination, receiptPath, receiptRoot);
   try {
+    if (request.receipt) receiptPath = canonicalReceipt(receiptPath, receiptRoot, destination, outputRoot);
+    if (request.uninstall) return uninstall(request, destination, receiptPath, receiptRoot);
     safePath(project, targets[request.target]);
     if (request.receipt) safePath(receiptRoot, receiptPath);
     if (inside(destination, receiptPath) && receiptPath === destination) throw Error('Receipt collides with destination');
@@ -274,7 +291,7 @@ export function install(request = {}) {
       if (info && entry.wrote) conflicts.push(entry.path);
     }
     if (conflicts.length) return result(3, `Preflight conflicts; nothing written:\n${conflicts.join('\n')}`);
-  } catch (error) { return result(3, `Preflight refused; nothing written: ${error.message}`); }
+  } catch (error) { return request.uninstall ? result(2, error.message) : result(3, `Preflight refused; nothing written: ${error.message}`); }
   const receipt = {
     schemaVersion: 1, package: packageInfo, date: new Date().toISOString(), mode: request.mode,
     target: request.target, scope: request.scope ?? 'project', destination, outputRoot,