Work Object Shell

Overview

The resolver chooses what the work needs to show. The shell renders that plan and uses the shared Shapeshift engine to stay anchored to the work. Opening a larger surface neither changes the evidence nor grants permission.

Walk the fixture with the step controls, or open the pill and use its available actions. These are modeled records, not connected inventory. A contract check does not establish source accuracy or a benefit for human supervisors.

Anatomy

1. Work identity. The object and its records remain referentially the same. The compact pill and expanded header are different presentations of that identity, not a promise that a header is always visible.
2. Anchored surface. The shell grows from the row that owns the work and returns to it. It does not become an unrelated modal.
3. Required disclosures. The active body carries the plan’s evidence, open questions, impact, authority or per-target results.
4. Bound controls. A control has an action, a reason and, where required, a version. The renderer does not invent another action.
5. Pending or verified summary. Collapsing preserves open work. A verified summary names the scope actually checked.

States

Compare the original approval with the changed version. Dana’s edit invalidates the old approval; it does not silently authorize the new target. Applying, outcome unknown, reading back and verified remain distinct.

Modes are representations, not a single progress scale: compact, compare, decide, authorize, execute, verify, recover and handoff. Independent state axes determine what each may claim.

Usage and avoid

When to use

Use one shell when a person must follow the same delegated work through changing evidence and decisions. Keep the application’s authoritative Case state outside the shell. Use a stable instance for that Case’s representation.

When not to use

Do not use a shell for an unrelated notification feed or ordinary navigation. Do not let a background update move focus into it, discard draft input, or replace an approval under the pointer (INV-09, MOT-05, MOT-07).

Keep an unknown result open

The next safe step is to determine the target’s outcome, not replay a write or present a completion badge. Unknown is neither failure nor success.

Evidence limits

The fixture demonstrates a bounded state model. It does not implement a production adapter, prove remote side effects, or establish that an adaptive shell outperforms a well-designed fixed interface.

Contract

Accessibility

The row, object identity and visible body need a coherent reading order. Expansion must be available by keyboard, not hover alone. Announce a background change politely without moving focus. A person’s expansion should place focus in the active representation; inactive content must not remain operable.

These are requirements, not an assertion of whole-site conformance. In particular, test a system update while focus is inside the shape that would leave, not only while focus is elsewhere. Reduced motion must keep every required disclosure readable.

Code

import { resolve, checkDom } from '../../packages/core/src/index.js';
import { buildSteps } from '../../packages/core/fixtures/mapping-case.js';
import { WorkObjectShell } from '../../packages/components/src/index.js';

const host = document.createElement('div');
document.body.append(host);
const shell = new WorkObjectShell(host);
const state = buildSteps().find(step => step.id === 'recover').state;
const plan = resolve(state);
shell.render(state, plan, { initiator: 'system', instant: true });
console.log(checkDom(host, plan));
// Fixture only. A production ly-action handler must revalidate at execution.

Continue with integration, input protection and evaluation boundaries.