Redesign Dialogue Lab case and turn identity

.agents/skills/dialogue-lab-closeout/SKILL.md

@@ -1,30 +1,28 @@
 ---
 name: dialogue-lab-closeout
-description: Close an Israel Facebook Dialogue Lab case after explicit user instruction, reported abandonment, no-response closure, or a clearly ended exchange. Use to validate closure, classify only observable outcomes, score the highest outcome, and record one controlled next test.
+description: Close an Israel Facebook Dialogue Lab case from observable evidence and record the result through one approval-gated SQLite transaction.
 ---
 
 # Dialogue Lab Closeout
 
 ## Required inputs
 
-- Target Case ID and the allowed closure condition.
+- Target Case ID and allowed closure condition.
 - Any final public turn, reaction, or user report needed to establish the observable ending.
 
 ## Workflow
 
-1. Read the complete live Manual, verify compatibility, record its revision, and validate the live Case Log schema.
-2. Load the complete Case and Turn graph. Run `dialogue-lab validate-parent-graph`; resolve any required missing public turn before closure.
-3. Verify privacy. Record observable chronology only. Never infer persuasion from silence, deletion, blocking, a reaction, or disappearance.
-4. Choose the Manual-allowed closed status, Outcome Class, and highest outcome score reached. Record concise Outcome Notes, What Worked, What Failed, and exactly one Next Test.
-5. Run `dialogue-lab validate-case` and `dialogue-lab validate-transition` on the planned result.
-6. Re-read relevant rows, Pending Sync, source revision state, and schema. Run source-consistency before the explicit-approval write.
-7. Read every written field back with `dialogue-lab verify-readback`. On failure, show PENDING SYNC and do not claim closure was recorded.
+1. Load the complete Case and Turn graph once with `case-show`.
+2. Resolve any missing public Turn through `$dialogue-lab-followup` before closure.
+3. Verify privacy and record observable chronology only. Never infer persuasion from silence, deletion, blocking, a reaction, or disappearance.
+4. Choose the closed status, Outcome Class, highest outcome score reached, concise Outcome Notes, What Worked, What Failed, and exactly one Next Test.
+5. Prepare one closeout payload. After explicit approval, run `dialogue-lab check`; if it passes, run exactly one `dialogue-lab case-close --case-id <id> <payload> --approved` transaction and report its compact receipt.
 
 ## Safety
 
-- Do not close a case solely because no new message is visible unless the user requests or reports no-response closure.
-- Do not alter canonical documents other than approved Case Log fields. Never post to Facebook.
+- Do not close solely because no new message is visible unless the user requests or reports no-response closure.
+- Never access or write `General responses`, and never post to Facebook.
 
 ## Output
 
-Return a compact closeout receipt containing Case ID, final status, Outcome Score, Outcome Class, observable basis, What Worked, What Failed, Next Test, Manual revision, source-consistency result, and read-back result.
+Return Case ID, final status, Outcome Score, Outcome Class, observable basis, What Worked, What Failed, Next Test, and read-back status.

.agents/skills/dialogue-lab-closeout/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Dialogue Lab Closeout"
   short_description: "Close a case from observable outcomes"
-  default_prompt: "Use -lab-closeout to close this Dialogue Lab case."
+  default_prompt: "Use $dialogue-lab-closeout to close this Dialogue Lab case."

.agents/skills/dialogue-lab-followup/SKILL.md

@@ -1,33 +1,27 @@
 ---
 name: dialogue-lab-followup
-description: Process a new public Facebook comment, reply, reaction, screenshot, text, or permalink in an existing Israel Facebook Dialogue Lab case. Use to extend the turn graph, resolve parentage with explicit confidence, update Active Exchange state, and recommend the next reply.
+description: Process supplied public content in an existing Israel Facebook Dialogue Lab case, resolve parentage, and prepare one approval-gated SQLite follow-up transaction.
 ---
 
 # Dialogue Lab Follow-up
 
 ## Required inputs
 
-- Existing Case ID or enough Post ID + Root Comment ID data to resolve it.
-- Exact new public turn or reaction, supplied URL, observed time, and any visible parent context.
+- Existing Case ID or enough Post ID + Root Comment ID and branch context to select one candidate.
+- Exact new public turn or reaction, supplied URL, observed time, and visible parent context.
 
 ## Workflow
 
-1. Read the complete live Manual and record its compatible version and revision state. Read the live Case Log schema and run `dialogue-lab schema-check`.
-2. Parse supplied URLs with `dialogue-lab parse-url`, preserve each exact URL, resolve canonical identity, and load the existing Case plus every relevant Turn.
-3. Assign or reuse only `P1`, `P2`, … or `USER`. Identify the direct parent from visible context or user confirmation; record Parent Confidence. Ask only when ambiguity materially changes the reply.
-4. Build the candidate incoming Turn, then run `dialogue-lab validate-turn` and `dialogue-lab validate-parent-graph`. Multiple children may share a parent. Show a compact Thread Map when the graph is branched.
-5. Load the live Strategy Guide and Evidence Base as needed, verify material claims, and answer the operative claim without treating private planning as public context.
-6. Produce the standard reply output. Ignore incidental abuse; use `no_engagement` for credible threats, doxxing, calls for violence, spam, or no testable claim.
-
-## Canonical write gate
-
-- Reads are automatic. Any Case/Turn append or update requires explicit approval and a Manual-allowed lifecycle action.
-- Before writing, re-read relevant rows, Pending Sync, source states, and schema; run source-consistency and case-local Turn ID allocation on the fresh rows.
-- After the runtime connector call, read the Case and Turn back and run `dialogue-lab verify-readback`.
-- On write or verification failure, show a complete PENDING SYNC record and do not claim Drive was updated. Never post to Facebook or write protected documents.
+1. Treat an explicit Case ID as definitive; otherwise use root-based `case-find` only for candidate discovery and select the Case from branch context, asking when multiple candidates remain materially ambiguous. Load the selected Case once with `case-show`.
+2. Parse supplied URLs with `parse-url`, preserve each exact URL, and confirm that the selected Case contains the tracked branch. Never identify a Case from its latest reply.
+3. When sibling branches already stored in one Case must be tracked independently, prepare one `case-split-branch` command with an outside-Git backup and exact new title/topic. After explicit approval, run `dialogue-lab check`; if it passes, run the split and use its committed Case/Turn mapping.
+4. Assign or reuse only `P1`, `P2`, ... or `USER`. Resolve the direct parent from visible context or user confirmation and retain Parent Confidence; ask only when ambiguity changes the reply.
+5. Build one incoming Turn payload. A supplied `reply_comment_id` is its strongest duplicate identity; without one, the transaction uses Case ID + Parent Turn ID (including a null root) + Direction + Exact Text. The transaction returns the existing Turn on a duplicate or allocates a Turn ID, validates the complete parent graph, appends, commits, and reads back.
+6. Read repository strategy and evidence Markdown only as needed, verify material claims, and answer the operative claim without treating private planning as public context.
+7. Return the standard output. After explicit approval, run `dialogue-lab check`; if it passes, run exactly one `dialogue-lab case-followup --case-id <id> <payload> --approved` transaction and report its compact receipt.
 
 ## Output
 
 Return, in order: `Case ID / Status`, optional `Thread Map`, `Claim Map`, `Recommended Reply`, `Shorter Version`, `Why This Approach`, `Fact Check`, `Conversational Potential`, `Log Tags`, and `Next Action`.
 
-Use the Manual's exact Next Action line and the Facebook thread's language.
+Use the Facebook thread's language. Ignore incidental abuse; use `no_engagement` for credible threats, doxxing, calls for violence, spam, or no testable claim.

.agents/skills/dialogue-lab-followup/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Dialogue Lab Follow-up"
   short_description: "Process a new turn in an existing case"
-  default_prompt: "Use -lab-followup to process this new public turn."
+  default_prompt: "Use $dialogue-lab-followup to process this new public turn."

.agents/skills/dialogue-lab-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dialogue-lab-intake
-description: Start or identify an Israel Facebook Dialogue Lab case from a public post, root comment, screenshot, text, or Facebook URL. Use for new-case intake, duplicate-case detection, claim mapping, fact checking, and a first reply recommendation; canonical Drive writes remain approval-gated.
+description: Start or identify an Israel Facebook Dialogue Lab case from supplied public content, resolve Case-ID or root candidates, and prepare one approval-gated SQLite intake transaction.
 ---
 
 # Dialogue Lab Intake
@@ -12,24 +12,15 @@ description: Start or identify an Israel Facebook Dialogue Lab case from a publi
 
 ## Workflow
 
-1. Read `config/drive-files.toml`. Through the Google Drive plugin, read the complete live Operating Manual and record its version plus revision or modified state. Run `dialogue-lab manual-version` and stop write preparation if compatibility fails.
-2. Read Case Log metadata, Cases/Turns headers, Data Dictionary enums/validations, and relevant current rows. Run `dialogue-lab schema-check` against the observed schema. Preserve the live schema.
-3. Parse every supplied Facebook URL with `dialogue-lab parse-url`. Preserve the exact URL; never infer a parent solely from `reply_comment_id`.
-4. Build `facebook:<Post ID>:<Root Comment ID>` with `dialogue-lab case-key`. Search Cases for that identity before allocating. If found, hand off to `$dialogue-lab-followup`.
-5. Extract the post, target and preceding public turns, first recorded comment, current case-local participant reference, material claims, hidden assumption, hostility, evidence confidence, privacy issues, and supplied URLs. Store no names or profile links.
-6. Load the live Strategy Guide and Evidence Base only as needed. Verify material current, historical, legal, military, statistical, and media-authenticity claims with current sources; separate fact, assessment, allegation, legal status, and moral judgment.
-7. Produce the standard output below. Do not write exploratory or intermediate drafts.
-
-## Canonical write gate
-
-- Read automatically; write only after explicit user approval at a Manual-allowed lifecycle point.
-- Immediately before a write, re-read relevant rows, unresolved Pending Sync, source revision state, and schema. Run the identifier, record, transition, graph, and source-consistency CLI checks.
-- Send only a typed Case Log append/update request through the runtime connector. Never write `General responses`, the Strategy Guide, or the Evidence Base here.
-- Read the exact row back and run `dialogue-lab verify-readback`. A connector success without a matching read-back is failure.
-- On failure, show a complete PENDING SYNC record and block new Case ID allocation. Never post to Facebook.
+1. Parse every supplied Facebook URL with `dialogue-lab parse-url`; preserve exact URLs and never infer a parent solely from `reply_comment_id`.
+2. Use an explicitly supplied Case ID as definitive. Otherwise run `dialogue-lab case-find` by `Post ID + Root Comment ID`, treat every result as a candidate, and compare its Turn graph with the supplied reply branch. Hand off an identified existing Case to `$dialogue-lab-followup`; an unmatched branch may become a new Case even when the Facebook root already has candidates.
+3. Extract the public context, case-local participant references, material claims, hidden assumption, hostility, evidence confidence, privacy state, and supplied URLs. Store no names or profile links.
+4. Read repository strategy and evidence Markdown only as needed. Verify material current claims with authoritative sources and distinguish fact, assessment, allegation, legal status, and moral judgment.
+5. Prepare one `case-intake` JSON payload containing the Case and initial public Turns. Do not persist exploratory drafts.
+6. Return the standard output. After explicit approval, run `dialogue-lab check`; if it passes, run exactly one `dialogue-lab case-intake <payload> --approved` transaction and report its compact receipt.
 
 ## Output
 
 Return, in order: `Case ID / Status`, `Claim Map`, `Recommended Reply`, `Shorter Version`, `Why This Approach`, `Fact Check`, `Conversational Potential`, `Log Tags`, and `Next Action`.
 
-Use the Manual's exact Next Action line. The public reply must use the thread language, focus on one pivotal point, sound natural, remain useful to silent readers, offer a face-saving path where warranted, and never fabricate evidence.
+The public reply must use the thread language, focus on one pivotal point, sound natural, remain useful to silent readers, offer a face-saving path where warranted, and never fabricate evidence.

.agents/skills/dialogue-lab-intake/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Dialogue Lab Intake"
   short_description: "Start or identify a Dialogue Lab case"
-  default_prompt: "Use -lab-intake to analyze this Facebook root-comment discussion."
+  default_prompt: "Use $dialogue-lab-intake to analyze this Facebook reply branch."

.agents/skills/dialogue-lab-posting/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dialogue-lab-posting
-description: Record a user's explicit confirmation that a Dialogue Lab reply was posted to Facebook. Use when the user says a reply was posted and supplies or confirms the exact published wording, permalink, identifiers, or posting time. This skill records state; it never publishes to Facebook.
+description: Record a user's explicit confirmation that a Dialogue Lab reply was posted, using one deterministic SQLite transaction; this skill never publishes to Facebook.
 ---
 
 # Dialogue Lab Posting Confirmation
@@ -9,25 +9,21 @@ description: Record a user's explicit confirmation that a Dialogue Lab reply was
 
 - Target Case ID and parent Turn ID.
 - Exact wording actually published, even when it differs from the recommendation.
-- Supplied permalink, IDs, and posting time when available.
+- Supplied permalink, identifiers, posting time, and optional Draft Turn ID.
 
 ## Workflow
 
-1. Read the complete live Manual, verify compatibility, and record its revision state. Read and validate the live Case Log schema.
-2. Resolve the case and parent turn. Parse any supplied URL with `dialogue-lab parse-url`; preserve it exactly and do not derive the immediate parent solely from `reply_comment_id`.
-3. Find an approved Draft row representing the posted reply. Update that row when appropriate; otherwise prepare a new Outgoing Posted Turn. Preserve exact published wording without rewriting it.
-4. Run `dialogue-lab validate-turn`, `dialogue-lab validate-transition`, and `dialogue-lab validate-parent-graph`. Update Case timestamps and status as the Manual requires.
-5. Re-read relevant rows, unresolved Pending Sync, source revisions, and schema. Run `dialogue-lab source-consistency` before the approval-gated connector write.
-6. Read every written field back and run `dialogue-lab verify-readback`.
-7. If writing or read-back fails, show a complete PENDING SYNC record and state that Drive was not verified.
+1. Load the Case once with `case-show`.
+2. Parse any supplied URL with `parse-url`; preserve it exactly. Use supplied `reply_comment_id` as the strongest duplicate identity, but resolve the immediate parent only from visible context or user confirmation.
+3. Prepare one Outgoing Posted Turn payload containing the exact published wording. Include `draft_turn_id` only when an existing Outgoing Draft must be marked Replaced.
+4. After explicit approval, run `dialogue-lab check`; if it passes, run exactly one `dialogue-lab case-record-posting --case-id <id> <payload> --approved` transaction. Without `reply_comment_id`, it deduplicates by Case ID + Parent Turn ID (including a null root) + Direction + Exact Text. It otherwise allocates the Turn ID, validates the graph and lifecycle, writes atomically, and reads back the committed state.
 
 ## Safety
 
 - Never publish, edit, or delete Facebook content.
 - Never assume the posted text equals an earlier draft.
-- Never write `General responses`, the Strategy Guide, or the Evidence Base.
-- Never treat connector acknowledgement as successful posting confirmation without matching Case Log read-back.
+- Never access or write `General responses`.
 
 ## Output
 
-Return a compact posting receipt containing Case ID, Turn ID, state, exact-text verification, URL/ID preservation status, Manual version and revision, source-consistency result, and read-back result.
+Return only the compact command receipt plus exact-text and permalink preservation status.

.agents/skills/dialogue-lab-posting/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Dialogue Lab Posting"
   short_description: "Record an explicitly confirmed posted reply"
-  default_prompt: "Use -lab-posting to record my exact published reply."
+  default_prompt: "Use $dialogue-lab-posting to record my exact published reply."

.agents/skills/dialogue-lab-strategy-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dialogue-lab-strategy-review
-description: Review strategy evidence across closed Israel Facebook Dialogue Lab cases. Use for comparable-case analysis after at least three cases, formal review at twenty closed cases, confounder-aware pattern assessment, and proposed Reply Strategy Guide changes that must not be applied without separate explicit approval.
+description: Review deterministic SQLite evidence across closed Israel Facebook Dialogue Lab cases and propose, but never apply, repository strategy-guide changes.
 ---
 
 # Dialogue Lab Strategy Review
@@ -12,19 +12,16 @@ description: Review strategy evidence across closed Israel Facebook Dialogue Lab
 
 ## Workflow
 
-1. Read the complete live Manual, record its compatible version and revision, validate the live Case Log schema, and read the complete live Reply Strategy Guide.
-2. Load only closed Cases and their relevant Turns. Reject fewer than three reasonably comparable cases. Label reviews below twenty total closed cases as preliminary.
+1. Read `docs/reply-strategy-guide.md` and load all closed Cases and Turns in one `dialogue-lab strategy-dataset` call.
+2. Reject fewer than three reasonably comparable cases. Label reviews below twenty total closed cases as preliminary.
 3. Compare topic, hostility, evidence confidence, reply length, thread position, and strategy. Separate commenter outcomes from silent-reader signals.
-4. Report sample sizes, contradictory evidence, missing data, and confounders. Do not infer causation from simple correlation or treat one case as a reusable finding.
-5. Distinguish supported findings, provisional hypotheses, and inconclusive results. Keep case-specific lessons in the Case Log.
-6. Draft the smallest exact Strategy Guide change only when the Manual's evidence threshold is satisfied. Do not apply it in this run.
+4. Report sample sizes, contradictory evidence, missing data, and confounders. Do not infer causation from correlation or treat one case as a reusable finding.
+5. Distinguish supported findings, provisional hypotheses, and inconclusive results. Keep case-specific lessons in SQLite.
+6. Draft the smallest exact Strategy Guide change only when evidence supports it. Do not edit the guide in this run; a separate explicit approval and reviewed repository change are required.
 
-## Write policy
+## Safety
 
-- Case Log and source reads may run automatically.
-- Never update the Strategy Guide without a separate explicit user approval for the exact proposed wording and a fresh source-consistency check.
-- Never write the Evidence Base or `General responses`, and never post to Facebook.
-- If a separately approved later write occurs, require revision recheck and connector read-back.
+- Never access or write `General responses`, and never post to Facebook.
 
 ## Output
 

.agents/skills/dialogue-lab-strategy-review/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Dialogue Lab Strategy Review"
   short_description: "Review strategy evidence across closed cases"
-  default_prompt: "Use -lab-strategy-review to review comparable closed cases."
+  default_prompt: "Use $dialogue-lab-strategy-review to review comparable closed cases."