osiman/SuperBizAgent-java
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(openspec): tighten run isolation contract

Browse Source
This commit is contained in:
zhuyongxin
2026-07-10 17:56:51 +08:00
parent 52bf0302c6
commit 6fdbd34bab
3 changed files with 22 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/session-run-trace-isolation/specs/session-run-trace-isolation/spec.md
+9 -9
View File
@@ -4,10 +4,10 @@
The system SHALL persist multi-turn conversation metadata in `chat_session` and one execution's auditable state in `diagnosis_run`.
#### Scenario: Valid Chat execution creates session metadata and a run
- **WHEN** a valid `/api/chat` request enters the Chat execution path with a `sessionId`
- **THEN** the system SHALL ensure a `chat_session` row exists for that `sessionId`
- **WHEN** a valid `/api/chat` request enters the Chat execution path and the service resolves an effective `sessionId`
- **THEN** the system SHALL ensure a `chat_session` row exists for the effective `sessionId`
- **AND** it SHALL create a new `diagnosis_run` row with a unique `run_id`
- **AND** the `diagnosis_run.session_id` SHALL equal the request `sessionId`
- **AND** the `diagnosis_run.session_id` SHALL equal the effective `sessionId`
#### Scenario: Invalid Chat request does not create a run
- **WHEN** a `/api/chat` request fails parameter validation before execution
@@ -15,7 +15,7 @@ The system SHALL persist multi-turn conversation metadata in `chat_session` and
#### Scenario: Chat session stores metadata only
- **WHEN** a Chat request completes
- **THEN** `chat_session` SHALL store metadata such as status, message pair count, created time, last active time, and expiration time
- **THEN** `chat_session` SHALL store metadata such as status, message pair count, created time, last active time, and optional expiration time
- **AND** it SHALL NOT store full conversation message history
### Requirement: Chat responses SHALL expose run identity
@@ -86,8 +86,8 @@ The system SHALL bind new feedback to a diagnosis run rather than an ambiguous m
#### Scenario: Feedback without runId falls back observably
- **WHEN** a legacy feedback request includes `sessionId` but omits `runId`
- **THEN** the system SHALL bind feedback to the latest run for that session
- **AND** the response or log SHALL include `fallbackToLatestRun=true`
- **AND** the response or log SHALL include the actual bound `runId`
- **AND** the response SHALL include `fallbackToLatestRun=true`
- **AND** the response SHALL include the actual bound `runId`
#### Scenario: Useful feedback creates case from run
- **WHEN** feedback for a run is `useful`
@@ -104,8 +104,9 @@ The system SHALL create and expose a diagnosis run for every valid `/api/ai_ops`
#### Scenario: AIOps SSE exposes runId
- **WHEN** `/api/ai_ops` streams response metadata to the caller
- **THEN** the stream SHALL expose the resolved `sessionId`
- **AND** it SHALL expose the created `runId`
- **THEN** the stream SHALL send a compatible metadata message before report content
- **AND** the metadata payload SHALL expose the resolved `sessionId`
- **AND** the metadata payload SHALL expose the created `runId`
### Requirement: Migration SHALL preserve historical trace access
The system SHALL migrate historical diagnosis data into compatibility runs without deleting the old `diagnosis_session` table.
@@ -144,4 +145,3 @@ The change SHALL verify both runtime behavior and evaluation baseline impact.
- **WHEN** verification is complete
- **THEN** the project SHALL run or explicitly evaluate the relevant baseline diff command
- **AND** any drift caused by run isolation SHALL be documented as expected or investigated as a regression