FCIS · REFRAME REFACTORING · PUBLISHED PROJECTION
GOVERNANCE CHAPTER · 10

Reference · Retained for architectural history and context; it is not, by itself, the current operational authority.

Copilot Implementation Extension

Chapter summary: This chapter extends the Grounding-first Reframe refactor to the application Copilot. It defines the required product behaviour, authority boundaries, implementation-discovery procedure, migration rules, and acceptance evidence. It does not prescribe unverified types, files, protocols, or call paths.

Purpose

Reframe contains a conversational Copilot intended to operate with the same legitimate access to the active Reframe workspace that the writer has through the application.

The Grounding-first refactor must therefore extend beyond the visible editorial pipeline. The Copilot must be migrated onto the same post-indexing authority model as the rest of Reframe.

The Copilot is not a separate source of truth, a second workflow engine, or an independent interpretation layer. It is the conversational means by which the writer may inspect, understand, direct, and operate the existing Reframe application.

The implementation objective is:

Every Reframe operation that the writer may legitimately perform through the application should be available to the Copilot through the same authoritative application behaviour, subject to explicit safety, cost, confirmation, and identity rules.

This does not mean that the Copilot may silently act without limits. It means that the Copilot must no longer be artificially weaker because it lacks access to application state or because its action vocabulary reflects obsolete architecture.

Relationship to the Grounding-first refactor

All authority rules defined by the Grounding-first refactor apply equally when an operation is initiated conversationally.

The Copilot must respect the same authority chain:

  1. canonical source text remains factual authority;
  2. confirmed Grounding provides the writer-confirmed interpretive and policy contract;
  3. Storify Source Auto is the sole structural reader of canonical source text;
  4. downstream artifacts remain derived artifacts with explicit identity and readiness;
  5. FountainStore persistence remains authoritative over transient UI state;
  6. source evidence must remain distinguishable from Grounding, derived interpretation, and model inference;
  7. removed semantic-index artifacts must not remain hidden Copilot dependencies.

A Copilot request must not bypass these contracts merely because it originates in natural language.

Required end state

After this extension is complete, the Copilot must be able to:

  • inspect the active Reframe project and explain its current state;
  • retrieve the same canonical source and persisted Reframe artifacts available through the application;
  • distinguish current, stale, missing, failed, incomplete, and unreadable artifacts;
  • explain what operations are currently available and why;
  • invoke legitimate Reframe operations through the application's existing operational boundaries;
  • request confirmation where the corresponding user operation requires confirmation;
  • expose cost-bearing or provider-bearing work before execution;
  • report the persisted result of an operation rather than merely claiming that it ran;
  • recover its understanding of the workspace after application relaunch;
  • refuse or visibly fail when required authority, evidence, readiness, provider access, or writer confirmation is absent.

The Copilot must not depend on semantic indexing, published semantic-memory objects, historical reading state, or obsolete index-derived readiness.

Non-goals

This extension does not authorize the coding agent to:

  • invent a new Copilot architecture before inspecting the existing one;
  • replace the application workflow with a generic agent framework;
  • create a second store beside FountainStore;
  • introduce a parallel command bus solely for the Copilot;
  • make conversation history authoritative application state;
  • infer writer confirmation from conversational tone;
  • expose every internal function directly to the model;
  • preserve semantic indexing as a private Copilot-only subsystem;
  • redesign unrelated UI, model-provider, or persistence systems;
  • assume that filenames or currently documented symbols still identify the implementation.

Implementation discovery is mandatory

Before proposing or editing the Copilot implementation, inspect the current Reframe source tree.

Do not begin from a presumed flow such as:

chat view
→ planner
→ interpreter
→ command
→ view model
→ store

That flow may or may not describe the current implementation.

Instead, establish the real implementation from evidence.

Required discovery questions

The coding agent must determine:

  1. Where does a writer's conversational turn enter the application?
  2. Which component constructs model context?
  3. Which persisted sources are available to that context?
  4. Which source or artifact retrieval paths already exist?
  5. How is intent represented after model inference?
  6. Is intent typed, textual, enumerated, generated, or interpreted dynamically?
  7. Which component decides whether an action may execute?
  8. Which component requests confirmation?
  9. Which component performs the operation?
  10. Which component persists the resulting state?
  11. How is success verified?
  12. How are failure and uncertainty returned to the conversation?
  13. Which Copilot operations still invoke indexing-era behaviour?
  14. Which application operations are currently unavailable to the Copilot?
  15. Which Copilot-specific paths duplicate behaviour already implemented elsewhere?
  16. Which generated manifests, capability declarations, IDL definitions, facts, or reasoning artifacts describe Copilot access?
  17. Which tests currently exercise the live conversational path?
  18. Which state survives relaunch, and which state exists only in memory?

Record the answers in PLANS.md with symbol names, source paths, and evidence.

Required searches

Search by behaviour and symbols, not only by guessed filenames.

At minimum, search for:

  • Copilot
  • chat
  • conversation
  • planner
  • intent
  • command
  • capability
  • operation
  • confirmation
  • approval
  • inference cost
  • provider
  • Grounding
  • Storify
  • Continuity
  • Cut Script
  • publish
  • FountainStore
  • semantic index
  • reading state
  • semantic memory
  • readiness
  • resume
  • failure
  • relaunch
  • generated reasoning
  • manifest
  • IDL
  • facts

Also search for user-facing strings corresponding to currently visible Copilot actions.

Implementation principle: reuse before extension

The Copilot must operate Reframe through the application's existing authoritative use cases wherever those use cases already exist.

For every Copilot action, determine whether Reframe already has an application-level operation used by the visible UI or another legitimate caller.

If it exists:

  • reuse it;
  • expose it through the existing intent or capability mechanism;
  • preserve its validation, persistence, telemetry, provider, cost, and failure behaviour;
  • do not reconstruct the operation inside the Copilot layer.

If it does not exist:

  • first determine whether the missing boundary is an application defect independent of the Copilot;
  • add the smallest reusable application-level operation;
  • use that operation from both the normal interface and the Copilot where appropriate;
  • do not create an operation callable only through model-generated text unless the behaviour is genuinely conversational.

The Copilot should add conversational access, not duplicate business logic.

Copilot perception contract

The Copilot requires a truthful representation of the current Reframe workspace.

This representation must be assembled from authoritative application and persisted state. It must not be reconstructed from prior assistant messages.

The coding agent must identify the current mechanism by which workspace state enters Copilot context and extend or replace that mechanism only as necessary.

The resulting perception contract must allow the Copilot to determine, where relevant:

  • active project identity;
  • canonical source identity;
  • source availability;
  • confirmed Grounding identity and status;
  • Storify identity, progress, readiness, and failure;
  • Cut Script identity and readiness;
  • Continuity identity, readiness, and findings;
  • publication state;
  • provider availability and provenance;
  • incomplete or resumable operations;
  • stale derived artifacts;
  • operations currently available;
  • operations currently blocked;
  • reasons for blocking;
  • whether confirmation is required;
  • whether an operation may incur inference cost.

Do not prescribe a new aggregate type merely to satisfy this document. First inspect whether the application already has snapshots, projections, manifests, readiness structures, or store queries that provide these facts.

Any new representation must be derived from existing authority rather than becoming authority itself.

Retrieval parity

The Copilot must have legitimate read access to the same project materials the writer can access through Reframe.

This includes, where applicable:

  • canonical source text;
  • source chapters, scenes, or line ranges;
  • confirmed Grounding;
  • Storify results and progress;
  • Cut Script artifacts;
  • Continuity findings;
  • publication state;
  • operational failures;
  • provider and telemetry information exposed by the application.

Retrieval must use current native application and FountainStore access.

Do not inject the entire project into every prompt merely to claim parity. Retrieval may remain scoped, selective, resumable, or mediated according to the existing model architecture.

Parity means that the Copilot can obtain the relevant material when needed, not that all material must always occupy model context.

The retrieval implementation must preserve distinctions between:

  • canonical source evidence;
  • writer-confirmed Grounding;
  • derived artifacts;
  • operational metadata;
  • model inference.

The Copilot must not report an inference as source fact.

Action parity

The coding agent must compare:

  1. operations the writer can initiate through Reframe;
  2. operations currently available to the Copilot;
  3. operations that should remain unavailable conversationally for safety or product reasons.

Create an evidence-based parity matrix in PLANS.md.

For each operation, record:

  • user-visible name;
  • current UI entry point;
  • current application operation;
  • current Copilot entry point, if any;
  • required persisted artifacts;
  • readiness conditions;
  • confirmation behaviour;
  • cost behaviour;
  • provider behaviour;
  • persistence effect;
  • telemetry effect;
  • failure result;
  • relaunch behaviour;
  • migration requirement.

Do not automatically expose low-level internal functions. Expose legitimate application operations at the level of writer intent.

Intent mediation

Natural-language requests must pass through Reframe's existing grounded intent-mediation architecture.

The coding agent must first inspect how Reframe currently converts a writer turn into executable application behaviour.

Extend that system rather than adding an unrelated model-to-function mechanism.

The final implementation must ensure:

  • model prose is not executed directly;