> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase19-session08-file-and-git/spec.md).

# Session Specification

**Session ID**: `phase19-session08-file-and-git` **Phase**: 19 - Orchestration Command Center Execution **Status**: Not Started **Created**: 2026-06-26 **Package**: null **Package Stack**: mixed TypeScript/JavaScript

***

## 1. Session Overview

This session implements file intent protection and Git workbench execution as the first concrete command-center executor families. It follows the completed attention, executor registry, and provider diagnostics sessions, so approvals, capability probing, execution runs, in-flight guards, and diagnostics posture are already available as foundations.

The work turns the existing generic file-intent scaffold into active write/edit conflict protection tied to owners, queue items, guarded actions, and bounded resolution choices. It also adds a local Git workbench that can preview and execute guarded Git operations while recording compact execution results and keeping broad UI surfaces limited to repo-relative labels.

The session remains local-first. It does not add terminal, container, remote, hosted, or Worker execution. Raw diffs, command bodies, terminal output, absolute paths, provider payloads, and secrets stay out of broad REST, WebSocket, hook, and web surfaces.

***

## 2. Objectives

1. Represent the required file and Git executor operations in shared protocol and guarded-action vocabulary without loosening redaction rules.
2. Add server-owned file intent and Git workbench managers with TTL cleanup, idempotency, conflict detection, bounded command execution, and audit-safe result summaries.
3. Promote current hook file-access and Git-guard observations into command-center file intent and attribution records where existing payloads support it.
4. Add web File/Git workbench surfaces that render live file-intent, dirty, conflict, execution, loading, empty, error, and offline states with product copy only.

***

## 3. Prerequisites

### Required Sessions

* [x] `phase19-session05-attention-and-permissions` - provides paired attention and permission decision audit state.
* [x] `phase19-session06-executor-registry` - provides guarded-action approval-to-execution wiring, registry probes, and execution runs.
* [x] `phase19-session07-provider-diagnostics` - provides command-center diagnostics posture and recovery boundaries.

### Required Tools Or Knowledge

* Node 26.2.0+ and npm 11.16.0 workspace commands from `.spec_system/CONVENTIONS.md`.
* Local Git CLI available to the server process for injected Git runner tests and bounded runtime commands.
* Current command-center protocol, server manager, route, WebSocket, store, hook, and Orchestration panel patterns.

### Environment Requirements

* No hosted credentials, provider API keys, Worker credentials, or analytics configuration are required.
* Git execution must degrade to explicit failed or unavailable results when a command cannot run locally within timeout, validation, or permission bounds.

***

## 4. Scope

### In Scope (MVP)

* Operators can declare, hydrate, and clear active write/edit/delete/move file intents with owner hero, operation, repo-relative path label, TTL, related task or guarded action, conflict state, and resolution action.
* Operators can see conflicting file work as actionable warnings tied to owners and tasks, with reassignment or override decisions recorded as local audit state.
* Operators can preview and execute guarded Git status, stage, unstage, commit, push, stash, revert, and branch-switch operations through the local executor registry when validation, risk guards, and permission state allow.
* Operators can see dirty state, conflict state, latest bounded Git result, and per-agent attribution where current file-access or tool-use data supports it.
* Server, hook, protocol, and web tests cover conflict checks, TTL expiry, Git previews, execution results, duplicate-trigger prevention, and redaction.

### Out Of Scope (Deferred)

* Terminal command execution - Reason: Session 12 owns terminal and container capability.
* Docker, remote, Worker, hosted, or channel executors - Reason: each requires separate threat, permission, and external-transfer boundaries.
* Broad raw path, diff, command body, or terminal output display - Reason: Phase 19 requires broad surfaces to use bounded labels and scoped details.
* Automatic conflict override without operator audit - Reason: this session must preserve explicit permission and audit trails.
* Production-hosted validation or push-success product claims - Reason: hosted and live remote claims remain no-claim without authorized evidence.

***

## 5. Technical Approach

### Architecture

Use the existing command-center contract and executor registry instead of a parallel execution path. Protocol changes are limited to the Git operations that are missing from the current shared enums and parser tests. Server state stays manager-owned: `fileIntentManager` handles normalized file-intent state, conflict checks, TTL cleanup, and resolution audit; `gitWorkbenchManager` handles preview planning, allowlisted Git command construction, timeout-capped execution, and redacted summaries through an injected runner.

The server wires both managers through existing `/command-center` routes, WebSocket update events, and guarded-action approval execution flow. Hook handlers continue sending compact observations only; server ingest promotes safe file-access and Git-guard fields into command-center records when enough metadata is present. The web app consumes typed API helpers, Zustand hydration, and a dedicated `FileGitWorkbench` component inside Orchestration.

### Design Patterns

* Protocol-first shared vocabulary: prevents server, hook, and web Git operation drift.
* Manager-owned state and snapshots: keeps TTL cleanup, filtering, idempotency, and broadcasts aligned.
* Injected runner with bounded output: makes Git execution testable and keeps raw command output out of public surfaces.
* Pure web normalization before store mutation: malformed command-center frames cannot blank the cockpit.
* Product-surface copy only: diagnostics and raw technical details stay in tests, docs, and scoped local details.

***

## 6. Deliverables

### Files To Create

| File                                                         | Purpose                                                                           | Est. Lines |
| ------------------------------------------------------------ | --------------------------------------------------------------------------------- | ---------- |
| `apps/server/src/managers/fileIntentManager.ts`              | Active file intent state, conflict detection, TTL cleanup, and resolution audit   | \~260      |
| `apps/server/src/managers/gitWorkbenchManager.ts`            | Bounded Git preview and execution manager with injected runner and risk guards    | \~360      |
| `apps/server/tests/fileIntentManager.test.ts`                | File intent conflict, TTL, idempotency, and redaction coverage                    | \~220      |
| `apps/server/tests/gitWorkbenchManager.test.ts`              | Git preview, command allowlist, execution result, timeout, and redaction coverage | \~280      |
| `apps/web/src/components/orchestration/FileGitWorkbench.tsx` | Dedicated File/Git Orchestration workbench surface                                | \~260      |
| `apps/web/tests/FileGitWorkbench.test.tsx`                   | Web workbench rendering, accessibility, duplicate guard, and redaction coverage   | \~240      |

### Files To Modify

| File                                                           | Changes                                                                         | Est. Lines |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------- |
| `packages/protocol/src/orchestrationCommandCenter.ts`          | Add missing Git executor kinds and parse coverage for file/Git records          | \~50       |
| `packages/protocol/src/guardedActions.ts`                      | Add guarded Git operation kinds required by the workbench                       | \~35       |
| `packages/protocol/tests/orchestrationCommandCenter.test.ts`   | Fixture round trips for expanded Git/file intent contracts                      | \~80       |
| `packages/protocol/tests/guardedActions.test.ts`               | Guarded Git operation parser and compatibility assertions                       | \~60       |
| `apps/server/src/managers/orchestrationCommandCenter.ts`       | Delegate active file intent updates and events to manager-owned state           | \~90       |
| `apps/server/src/managers/executorRegistry.ts`                 | Register file and Git executor-ready entries with probes and execution adapters | \~180      |
| `apps/server/src/lib/commandCenterValidation.ts`               | Add file conflict and Git workbench request validation                          | \~120      |
| `apps/server/src/routes/commandCenter.ts`                      | Add conflict check, resolution, Git preview, and Git execution routes           | \~160      |
| `apps/server/src/routes/guardedActions.ts`                     | Connect approved Git guarded actions to the Git workbench executor path         | \~70       |
| `apps/server/src/lib/eventIngest.ts`                           | Promote safe hook file and Git observations into command-center records         | \~100      |
| `apps/server/src/server.ts`                                    | Instantiate and inject the new managers and registry entries                    | \~45       |
| `apps/hooks/src/factionos-file-access.js`                      | Include compact repo-relative attribution metadata when available               | \~45       |
| `apps/hooks/src/factionos-git-guard.js`                        | Include compact Git operation/risk metadata without command body leakage        | \~45       |
| `apps/hooks/tests/hookRuntime.test.js`                         | Validate file/Git attribution payloads and observer restrictions                | \~100      |
| `apps/web/src/lib/orchestrationApi.ts`                         | Add typed file conflict and Git workbench API helpers with in-flight guards     | \~140      |
| `apps/web/src/lib/commandCenterUi.ts`                          | Add file/Git state summaries, redaction, and action availability helpers        | \~120      |
| `apps/web/src/components/orchestration/CommandCenterPanes.tsx` | Wire File/Git workbench into Orchestration panes                                | \~60       |
| `apps/web/src/components/orchestration/index.ts`               | Export the new workbench component                                              | \~10       |
| `apps/web/tests/orchestrationApi.test.ts`                      | API helper coverage for conflict checks and Git workbench requests              | \~120      |
| `apps/web/tests/commandCenterUi.test.ts`                       | File/Git view and redaction helper coverage                                     | \~80       |
| `docs/api/README_api.md`                                       | Document shipped file intent and Git workbench routes and boundaries            | \~80       |
| `docs/api/event-api-hook-contracts.md`                         | Document hook promotion, Git guard, and WebSocket event behavior                | \~80       |
| `apps/server/README_server.md`                                 | Update server route and manager ownership notes                                 | \~50       |
| `apps/web/README_web.md`                                       | Update Orchestration File/Git workbench contract                                | \~60       |
| `apps/hooks/README_hooks.md`                                   | Update hook attribution and Git guard boundaries                                | \~45       |

***

## 7. Success Criteria

### Functional Requirements

* [ ] Conflicting write/edit/delete/move file intents surface as actionable warnings tied to owner heroes, related tasks, and guarded actions.
* [ ] File intent TTL expiry, reassignment, override, and clear operations emit live command-center updates and preserve local audit metadata.
* [ ] Git proposals can be approved or rejected and approved executor-ready operations record bounded execution results.
* [ ] Dirty, conflict, and file-intent states update live in the Orchestration panel without exposing raw absolute paths, diffs, or command bodies.
* [ ] Per-agent attribution appears when current hook file-access or Git-guard data contains safe session, hero, task, or mission references.

### Testing Requirements

* [ ] Protocol tests cover expanded Git operation vocabulary and file intent parsing.
* [ ] Server manager and route tests cover conflict checks, TTL cleanup, Git previews, execution results, timeout/failure paths, and duplicate triggers.
* [ ] Hook tests cover compact file/Git attribution and restricted Git-guard behavior.
* [ ] Web tests cover loading, empty, error, offline, conflict, dirty, and executed states plus redaction.

### Non-Functional Requirements

* [ ] Local execution uses explicit validation, authorization, audit fields, timeout, bounded output, and rollback or cleanup notes.
* [ ] Broad UI and WebSocket frames use repo-relative labels and redacted summaries only.
* [ ] Git push and other external-touching operations degrade to failed or unavailable results when safe local execution cannot be proven.

### Quality Gates

* [ ] All files ASCII-encoded
* [ ] Unix LF line endings
* [ ] Code follows project conventions
* [ ] Primary user-facing surfaces contain product-facing copy only
* [ ] Root format, lint, typecheck, and test gates pass or failures are recorded with exact residual risk

***

## 8. Implementation Notes

### Working Assumptions

* `Package: null` is correct because the selected session spans protocol, server, hooks, and web. The candidate stub names `apps/server`, `apps/web`, and `apps/hooks`, while repo conventions require protocol-first updates for shared executor and guarded-action vocabulary. Planning can proceed because the additional protocol work is narrow and directly required by the session scope.
* Existing file-intent DTOs, `/command-center/file-intents`, WebSocket hydration, and executor registry scaffolds are the foundation. Repo evidence shows `CommandCenterFileIntent`, `command_center_file_intent_update`, generic file-intent REST routes, and default Git executor entries already exist, so this session should extend them instead of replacing them.
* Git execution can be executor-ready only for validated local commands that complete within timeout and return bounded summaries. The PRD includes Git push in scope, but preserved hosted and production validation no-claims mean push success must not become a production-hosted claim.

### Conflict Resolutions

* The session stub package list omits `packages/protocol`, but `CONSIDERATIONS.md` says protocol leads shared queue, guarded-action, event, REST, WebSocket, and domain changes. The chosen interpretation is to include a small protocol task for missing Git kinds before server and web work.
* The master PRD says real file/git executors are deferred without threat model, permission, audit, tests, and docs, while Phase 19 Session 08 says file and Git execution are in scope. The chosen interpretation is that this session may implement file/Git only through registry-gated executor-ready entries with validation, audit, redaction, timeout, tests, and docs; unsafe or unsupported operations return explicit failed or unavailable states.

### Key Considerations

* Execution families must stay registry-gated and permission-backed.
* Broad command-center views must use repo-relative labels and bounded summaries.
* Hook payloads remain observations and cannot rely on hook ordering to prevent another tool from mutating files or Git state.
* Manager-owned cleanup and snapshot emission should keep file-intent state deterministic across REST, WebSocket, and tests.

### Potential Challenges

* Git commands can leak paths, diffs, or remote output: build summaries from parsed status/result metadata and redact runner stdout/stderr before storage.
* File intent conflict checks can race: use manager-level idempotency keys and state revision checks closest to the mutation boundary.
* Existing generic panes can bury actionable file conflicts: add a dedicated File/Git workbench instead of relying only on overview rows.

### Relevant Considerations

* \[P03] **Real executors remain unimplemented by design**: This session closes only file and Git families with explicit threat, authorization, audit, tests, and docs; other executor families remain deferred.
* \[P03-packages/protocol] **Protocol leads cross-package work**: Shared Git and file intent contract changes land before server, hook, and web wiring.
* \[P07] **Redaction is boundary-specific**: REST, WebSocket, hook, local logs, and web UI each need bounded labels and summaries.
* \[P03-apps/server] **Local server boundary must stay conservative**: New routes need validation, auth/rate-limit middleware coverage, body-size limits, and explicit errors.
* \[P18-apps/server] **Manager-owned persistence and snapshot emission**: Expanded command-center managers should keep filtering, state, and broadcasts aligned.
* \[P18-apps/web] **Pure normalization before store mutation**: Web reducers should normalize malformed or partial file/Git payloads before Zustand state changes.
* \[P10-apps/cli+apps/hooks] **Do not mutate user-owned Codex config**: Hook changes must stay in source handlers and tests, not installer behavior.

### Behavioral Quality Focus

Checklist active: Yes Top behavioral risks for this session:

* Duplicate guarded approvals or Git workbench clicks could run a mutation twice.
* Conflict checks could miss stale or expired file intents during async cleanup.
* Git output, broad paths, diffs, tokens, or command bodies could leak through summaries, WebSocket frames, hook logs, or UI rows.

***

## 9. Testing Strategy

### Unit Tests

* Protocol parser tests for expanded Git kinds and file-intent payloads.
* Server manager tests for file conflicts, TTL expiry, idempotency, Git allowlists, Git preview summaries, timeout results, and redaction.
* Web helper and component tests for action availability, state labels, duplicate-trigger disabled states, and redaction.

### Integration Tests

* Server route tests for file-intent conflict checks, resolution mutations, Git preview/execution routes, guarded-action approvals, and WebSocket update frames.
* Hook runtime tests for file-access and Git-guard compact attribution payloads.

### Runtime Verification

* Run focused protocol, server, hook, and web test files.
* Run root format, lint, workspace typecheck, and test commands.
* If a local server smoke is used, verify the File/Git workbench loads disconnected, empty, conflict, and executed states without raw local data.

### Edge Cases

* Expired file intents are pruned before conflict decisions.
* Multiple heroes declare write/edit intent for the same repo-relative path.
* Malformed or absolute paths are rejected or redacted before storage.
* Git command runner times out, exits nonzero, reports conflicts, or produces raw diff-like output.
* Push or branch operations are unavailable or failed when local Git state or remote access cannot be validated safely.

***

## 10. Dependencies

### Other Sessions

* Depends on: `phase19-session05-attention-and-permissions`, `phase19-session06-executor-registry`, `phase19-session07-provider-diagnostics`
* Depended by: `phase19-session09-heroes-and-lineage`, `phase19-session10-mission-artifacts`, `phase19-session12-terminal-and-containers`, `phase19-session16-ergonomics-and-documentation`

***

## Next Steps

Run the `implement` workflow step to begin implementation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase19-session08-file-and-git/spec.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.