Director Pattern v1.1.0

Director Pattern v1.1.0

October 27, 2026

This release makes the intended result and continuing supervision explicit, while
separating the replaceable engine from project-owned integration.

• Choose the intended deliverable before applying the direct-answer exception.
  Concrete product feedback can call for bounded implementation or rendered
  alternatives even when phrased tentatively. Explicit discussion-only requests
  stay conversational.
• Keep the original user request and its completion obligations through delegated
  work. Parent project/request references connect each owner’s requirements,
  observed status, returned records, and evidence without requiring a new tracker
  for every small task.
• Observe active assignments, wait through supported host tools, evaluate returns,
  and request rework before acceptance. Delegating to a subordinate director does
  not transfer away supervision. A status reply or proposal closes no work.
• Proactively send a labeled 📋 SitRep about every five minutes, or at the
  user/project interval, while delegated work is outstanding. Ordinary progress
  and status questions do not replace or reset it. Start timing at actual
  dispatch and report promptly on resume when due timing is unknown or overdue.
• Reconcile unfinished work at active project startup using real execution and
  artifact evidence. Resume within existing authority; do not infer a blocker,
  termination, or permission to restart from stale records or silence.
• Install generic contracts and helper implementations under engine/, keeping
  project roles, policy, context, identities, trackers, and state project-owned.
  Explicit ownership lists and compatibility launchers preserve the existing
  helper roots and request-store schema.

Existing flat installations need the reviewed one-time layout integration in the
ownership boundary.
Back up and compare the accepted baseline, preserve local adaptations and project
records, repair the existing bridge/index references, and validate affected startup
routes before accepting adoption. This is an instruction-layout transition, not a
tracker migration: config/request-store schemas and project/request identities do
not change. Later compatible engine updates preserve project-owned neighbors.

Publication, spending, external messages, human acceptance, and host continuation
limits remain governed by existing authority. The package installs no daemon or
scheduler and cannot keep a model alive after its host ends execution.

Validation includes 55 development tests, eight site tests, and bounded browser
and HTTP checks. A fresh supervised runtime trial observed a real running worker,
a status reply during execution, rejection of an intentionally incomplete return,
and corrected rework from the same child before evaluation. A fresh recovery
reader checked stale running status against actual completion and the final
artifact without restarting completed work. These controlled, prompted trials do
not establish five-minute cadence, host-interruption recovery, unassigned Director
auto-discovery, or universal future-host reliability.

Detailed scope and remaining behavioral limits are recorded in
development/DESIGN_NOTES.md. Local checks establish the
behavior actually observed; acceptance and publication remain separate claims.