> 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/phases/phase_11/session_02_test_fixture_hardening.md).

# Session 02: Test Fixture Hardening

**Session ID**: `phase11-session02-test-fixture-hardening` **Status**: Not Started **Estimated Tasks**: \~16-24 **Estimated Duration**: 2-4 hours

***

## Objective

Harden Codex fixtures and focused automated coverage across protocol, hooks, CLI, server, and web packages.

***

## Scope

### In Scope (MVP)

* Add source-backed Codex fixtures for lifecycle, Bash, `apply_patch`, permission requests, subagents, unknown events, and compaction events if used.
* Run protocol, hook package, CLI, server, and web test suites affected by the integration.
* Tighten redaction and bounded-payload assertions where fixtures expose gaps.
* Fix only defects required for reliable automated coverage.

### Fixture And Test Matrix

* Protocol: `HeroCli` includes `codex-cli`; hook event constants include Codex lifecycle events; Claude aliases still compile.
* Hooks: `hooks.codex.json` maps events to expected commands; commands include `FACTIONOS_CLI=codex-cli` and resolved package root.
* Hooks: `SessionStart` fixture uses `session_id`, `hook_event_name`, `cwd`, and `model` and posts `cli: "codex-cli"`.
* Hooks: `UserPromptSubmit` fixture uses `prompt` and starts a mission payload.
* Hooks: `PreToolUse` Bash fixture reads `tool_name`, `tool_input.command`, and `tool_use_id`.
* Hooks: `PreToolUse` `apply_patch` fixture reports bounded file edit metadata and omits raw patch bodies.
* Hooks: `PermissionRequest` fixture reads `tool_name`, `tool_input`, and optional `tool_input.description`.
* Hooks: `SubagentStart` and `SubagentStop` fixtures use `agent_id` and `agent_type`.
* Hooks: spool and log sanitization cover `prompt`, `tool_input`, `tool_response`, `transcript_path`, `agent_transcript_path`, and MCP args.
* CLI: `init --cli claude`, `init --cli codex`, `init --cli all`, malformed hooks, idempotent reinstall, uninstall, status, and doctor are covered.
* Server: full lifecycle fixture covers Bash, `apply_patch`, permission, subagent, unknown event fallback, and `cli: "codex-cli"` persistence.
* Web: hero cards, hero detail, mission filters, tool categorization, replay, and export redaction cover Codex-shaped payloads.

### Out of Scope

* Full repository refactors.
* Hosted integration tests.
* Live provider transfer or telemetry.

***

## Prerequisites

* [ ] Session 01 complete.
* [ ] Codex fixture source notes documented.
* [ ] Focused package test commands identified.

***

## Deliverables

1. Redacted Codex fixtures for lifecycle and tool events.
2. Focused automated tests across affected packages.
3. Redaction assertions for prompt, patch, transcript, terminal, path, and token boundaries.
4. Notes on any fixture-backed limitations.

***

## Success Criteria

* [ ] Focused automated suites pass with both Claude and Codex fixtures.
* [ ] Fixtures do not include raw prompts, token-like values, transcript bodies, or terminal output.


---

# 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/phases/phase_11/session_02_test_fixture_hardening.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.