investigate: harness-layer ideas from @yyz81681981 (PTC, spatiotemporal context, dreaming cycle) #4

Source

https://x.com/yyz81681981/status/2050010715663257601?s=20 — quoted excerpt:

The real leverage is at the Harness layer:

• Spatiotemporal management of context (spatial context vs. temporal context)
• PTC execution model (Plan → Tool → Critique)
• Sub-agent isolation + proactive memory (similar to Iris's dreaming cycle)
• Constraint files / Skills as config, rather than rewriting the system prompt every time

Why this matters

The harness skill in this repo already implements adjacent ideas — operating-contract CLAUDE.md, hook-driven feedback loop (Stop → harness-check.sh), auto-memory, slash commands (/plan, /verify). The four bullets above name patterns that may already be present, partially present, or worth borrowing. Worth a structured read-through before deciding what (if anything) to pull in.

Investigation

For each bullet, answer:

1. Spatiotemporal context management — spatial vs. temporal

   • What does the author mean? Find the original thread or any prior writing they've linked.
   • How does our harness handle each today? (e.g. CLAUDE.md is spatial; auto-memory + post-compact-reinject.sh is temporal.)
   • Gaps?

2. PTC execution model — Plan → Tool → Critique

   • Compare to the existing /plan command and the verify-before-stop.sh gate. Is "Critique" a missing third leg, or is harness-check.sh already serving that role?
   • Is there a richer critique pattern worth adopting (self-review pass, structured failure modes)?

3. Sub-agent isolation + proactive memory

   • The Iris "dreaming cycle" reference — find a primary source. What is it?
   • Where would proactive memory updates fit? (Currently auto-memory updates reactively when the agent learns something; a dreaming-cycle style would consolidate/prune on a cadence.)

4. Constraint files / Skills as config

   • Already aligned: this repo is skills-as-config. Confirm there's nothing implied beyond what we already do.
   • Is the author pointing at a specific format (YAML constraints, policy files) that would extend our model?

Deliverable

A short writeup in docs/notes/ (or comment on this issue) with:

• One paragraph per bullet
• Verdict: already-have / worth-borrowing / not-applicable
• For "worth-borrowing": a follow-up issue draft

Pointers

• Source: https://x.com/yyz81681981/status/2050010715663257601?s=20 (capture thread context too)
• Existing harness surface: skills/harness/SKILL.md, skills/harness/assets/, scripts/harness-check.sh
• Adjacent skills: write-a-skill, improve-codebase-architecture