BR-02 / detailed resource room
A reusable block is an admitted artifact, not a copied repository. This room expands the framework report: what counts as a block, the proposed dossier, eligibility/admission rubric, staged adaptation protocol, quarantine policy, automation boundary, first-pilot envelope, ownership and rollback.
manifest-backed provenance required visual + build proof human admission
01 / Definition
What counts as a reusable block From the framework report, not a loose metaphor.
Definition
A block is a manifest-backed installable item with a known interface, provenance, license, test evidence, and rollback boundary.
It can be a UI/CRUD surface, data adapter, workflow node, scaffold module, or agent-operation capability. The unit is not “the repo.” The unit is the smallest controlled artifact that can be installed, adapted, tested, and removed.
Why the repo is not the unit A repository contains more code and dependencies than the intended capability. Its README rarely states transformation or ownership boundaries. Its visual/demo success does not prove production behavior. Its data model may be coupled to provider-specific services. Its license may not cover the assembled/adapted artifact.
02 / Proposed block dossier
The fields that make an artifact inspectable Every field becomes a reviewable receipt.
identity Source + lineage Block ID, source URL, pinned commit, fork, extracted paths, transformation history, owner, and intended capability.
contract Interface + dependencies Inputs, outputs, routes, data schema, environment variables, required services, provider coupling, and allowed side effects.
evidence Receipts + verdict License, SBOM, static/AST, unit/build, browser, screenshot, accessibility, human review, admission state, and rejection/quarantine reason.
adaptation What changed Original versus adapted files, token substitutions, schema changes, removed features, generated code, and reason for every transformation.
runtime Data + authority Tenant boundary, secrets, migrations, read/write surface, approval checkpoints, idempotency, retries, read-back, recovery.
ownership Release + rollback Named owner, release date, rollback artifact, data recovery plan, deprecation path, and acceptance decision.
03 / Admission rubric
Evidence gates, in the order they should run Candidate selection does not skip gates.
Gate Question Receipt Stop condition Provenance Do we know what source and commit this came from? URL, pin, extraction map, source integrity. Unknown source, mutable tip, or unverifiable lineage. License Can the assembled/adapted artifact be used and redistributed? SPDX result, obligations, dependency/asset scan. Unknown, incompatible, or unreviewed license. Static / AST Can we understand the code and find dangerous surfaces? Scanner output, dependency tree, AST findings. Unbounded eval/exec, secrets, hidden side effects. Data What data does it read/write, and who owns it? Schema/tenant map, migration plan, fixture proof. Provider coupling or write authority not bounded. Build / smoke Can the adapted block deterministically install and run? Install, typecheck/build/test/browser logs. Sandbox green only, flaky or irreproducible output. Visual Does it honour the approved direction and interaction contract? Screenshot baseline/diff, accessibility, review. Unbounded visual drift or inaccessible critical flow. Human Who accepts the risk and owns rollback? Named decision, release/rollback record. No accountable owner or recovery path.
04 / Staged adaptation
How the agent is allowed to touch a candidate Constrain edits by layer.
stage 0 Observe Read source, manifest, license, dependency graph, screenshots, routes, and data model. No edits or installs in the shared tree.
stage 1 Extract Copy only the intended capability into a disposable workspace; produce the block manifest and ownership map.
stage 2 Normalize Map tokens, routes, schema, imports, and provider boundaries to the Actionist contract. Record every transformation.
stage 3 Validate Run source/license, static, build, unit, browser, screenshot, and human gates with repair capped and logged.
stage 4 Admit or quarantine Admit only with a complete envelope; otherwise preserve evidence and quarantine the candidate with a reason.
stage 5 Release / rollback Ship behind an owner and reversible boundary. Observe, compare, and retire without orphaning data or dependencies.
05 / Smallest first pilot
Read-only UI/CRUD is the deliberately boring start Recommendation from the framework report.
Start with one narrow, permissive, read-only UI/CRUD block and prove the whole envelope.
Why read-only
It constrains side effects while still proving visual fit, routes, schema, registry, build, and browser behavior.
What to measure
Time to admit, adaptation churn, repair count, token fidelity, build repeatability, evidence completeness.
What it unlocks
Only after this works: write adapters, vertical atoms, agent actions, and larger composite blocks.
Current state: the framework is complete as a proposal, but no candidate has passed every gate. “Framework ready” is not “library populated.”
06 / Evidence shelf
Open the 816-line framework report Local report copy is kept under the pack.
816 lines Reusable-block framework report Initial landscape, definition, dossier, rubric, staged adaptation, coverage ledger, final pilot, rollback, and verdict.
Open full report ↗ AM gate Corpus admission plan Machine-readable cluster-007 execution sequence used by the AM corpus lane.
Open AM gate plan ↗ contract Block contract schema Schema reference for the machine-readable artifact envelope.
Open schema ↗ design Local block framework Action Model-specific block framework and implementation boundary.
Open design framework ↗ Local source reader full report text on demand
framework report block framework schema.json
Choose a source above. The local reader loads the original artifact.