Ffe Spec Book

/as:ffe-spec-book — Assemble an FF&E Specification Book

Before acting, read the host contract and this component's declaration (skill:ffe-spec-book). Load only its referenced mode profiles from the shared catalog. Compose modes required by the actual task; declarations are requirements, not proof of access or permission.

<!-- architecture-studio:harness-compatibility -->

Host adapter: read delivery-specific guidance for invocation, package paths, questions, file access and optional delegation.

Compose /as:product-cut-sheet; do not duplicate extraction, research or sheet layout logic. Input: explicit ordered scope, pinned schedule/item revisions or a one-off snapshot, accepted template, grouping and audience. Output: individual/combined artifacts as requested and a derived package preparation manifest and revision receipt owned by this skill. /as:product-data-import owns the accepted job input manifest; this skill only consumes it. Item/schedule records remain owned by /as:master-schedule; decisions and project facts remain owned by /as:project.

Document role and compatibility

Assemble an FF&E specification book from source-faithful product entries. Project Manual sections and their design, submittal and execution requirements belong to /as:spec-writer. The skill name is ffe-spec-book; the persisted document kind spec-book, template IDs/paths, helper operations and existing receipts retain their current contracts. Do not migrate saved records merely because the skill name changed.

Native preparation and publication

Read the complete native output owner and design resolver, including exact schemas, identity/versioned filenames, hashes and retry boundaries. Use the actual host's native tooling; operation names identify semantic work and do not dispatch an Arch Studio executable.

Follow Inspect → Prepare → Verify preparation → Apply → Verify result → Complete. The whole affected preparation set is the new manifest, projected data and every image asset; guard full source/template/design/current record pins. For verification, the whole set is the receipt, its immutable companion evidence and actual artifacts. Finish durable saves and separately reopen and validate all full saved originals/prepared bytes and access metadata before the first publisher. Inspect pending state before preparing or allocating another revision. Publish complete file bytes without clobbering prior jobs, then freshly read back every actual destination and dependency, including access metadata, before completion. Real every-page visual/link/privacy inspection is required; a hash or supplied flag does not substitute for an inspection.

1. Resolve and freeze the package

For project-bound work resolve the valid PROJECT.md, read instructions and preserve malformed/unindexed records. Select a registered project only when the requested durable work needs it; never create one implicitly. A one-off package uses the authorized task folder with no studio/project gate. Do not infer context from plugin installation. Preserve originals and use project/task-relative references. No issue/approval state is inferred from artifact generation.

Reuse authorization and supplied corrections. Ask once only if a material choice remains unresolved; combine exact target, scope, template, audience and effects in the single gate. For an adopted schedule, pin the full schedule ID/revision/hash and each selected item ID/revision using the native record owner’s complete current-read procedure. For one-off work, explicitly pin a source snapshot without adoption. Do not let an older workbook, cached scope or historic output package replace a corrected accepted source. Schedule updates, workbook reconciliation and recovery route to their owner.

Build an explicit ordered expected-tag list. Define product-versus-finish grouping through outputs[].item_ids; never assume one spreadsheet row equals one sheet. Omissions require recorded user authorization and a revised scope; a missing or failed item is not an authorized omission. Preserve exact tags and isolate filenames by unique ffe/jobs/<job-id>/<revision>/ folder.

Follow the shared identity and versioned filename contract. Keep dotted tags unchanged. Use the current filename contract and exact item identifiers; never infer canonical retagging.

Accepted input handoff and derived projection

Derive the expected denominator from the full accepted input scope, not just successfully parsed products. Keep all requested categories, including lighting. Maintain one ledger entry per requested item: verified artifact reference/hash, or unresolved with a precise reason. An unresolved row accounts for the item but does not complete its sheet. Use delivery_coverage.assess from the native evidence contracts to screen the ledger; it does not replace actual ffe_outputs.check or visual inspection. Report expected, accounted-for, verified and unresolved counts separately. Never shrink scope to match the files produced. Before returning links, perform native delivery_coverage.verify-links with one expected entry per artifact containing current item/revision/source/template hashes, actual artifact and receipt paths, and immutable companion evidence path/raw hash. It reads the linked files and receipts and rejects stale identities, revisions or hashes; a supplied ledger alone does not establish that the returned links are current.

Consume ffe/jobs/<job-id>/input-manifest.json from /as:product-data-import, using the intake schema. If it is absent, hand off to that owner to record the supplied sources and scope under existing authorization; one-off mode records inputs without adopting a schedule. Verify its input_hash, source hashes/status, selected tags, accepted template and adopted record_basis when present. Reconcile explicit product/finish grouping with that selection. Corrections produce a superseding input job through the owner, never an output skill's rewrite of the accepted manifest.

Preserve the untouched joined record read (or one-off source extraction) separately. Create a derived output snapshot, retaining schedule ID/revision/hash and item ID/revision while selecting only the accepted scope. Put accepted input_hash, source references/status, selected tags and the original record source in the snapshot's source object; an empty record source is not invented evidence. Record the raw-read hash and explicit field mapping separately in the preparation evidence. The output snapshot is a rendering projection, not a newly signed canonical record.

Map structured values deliberately into the output contract’s scalar render fields. For a stored hyperlink {label,url}, retain separate display-label and true-URL fields and explicitly allowlist the intended fields; never replace the URL with its label. Preserve the raw structured value and mapping in private preparation evidence. Other nested values require an explicit lossless source-to-display mapping, not guessed flattening. The host must create and inspect actual PDF link annotations, not merely print URL-looking text. Never mutate adopted records to satisfy a renderer's input schema.

Before verification or resume, reread current canonical data and accepted input evidence, then rebuild the same derived projection and mapping. Compare it with the prepared inputs; changed source/scope/mapping/revisions invalidate affected outputs. Keep all raw evidence and preparation controls outside client delivery.