Skip to content

spec: F013 Frame Splitting — feature spec, review, impl spec 012.1#102

Open
tfatykhov wants to merge 1 commit intomainfrom
spec/F013-frame-splitting
Open

spec: F013 Frame Splitting — feature spec, review, impl spec 012.1#102
tfatykhov wants to merge 1 commit intomainfrom
spec/F013-frame-splitting

Conversation

@tfatykhov
Copy link
Copy Markdown
Owner

F013 Frame Splitting

3 documents added:

docs/features/F013-frame-splitting.md — Feature spec
docs/reviews/F013-3-agent-review.md — 3-agent review (composite: 7.0/10)
docs/implementation/012.1-frame-splitting.md — Implementation spec

Key Design Decisions
• New split_frames tool (not extended spawn_task) — blocking semantics are fundamentally different
• Split → Execute → Synthesize pattern
• V1 scope: inline synthesis only, no recursive splits, no auto-detection, no DAG dependencies
• Sub-agents always inherit censors, never get split_frames tool
• Max 5 sub-agents, 120s total timeout

Build Plan (012.1)
• Phase 1 (~4-6h): Frame-aware subtask worker — frame_type + split_id in Subtask model
• Phase 2 (~3-4h): split_frames tool + sync barrier, async gather with timeout, partial failure handling
• Phase 3 (~2-3h): Result enrichment, cost metrics, status messages during execution

Review Scores
• Architecture: 7.0/10
• Implementation: 6.5/10
• Research: 7.5/10
• Composite: 7.0/10

Risk Flags
• Cost explosion (5 agents × 5 turns = 25 API calls)
• Synthesis quality
• Inter-dependencies need DAG in v2

+984 lines across 3 files

…012.1

- F013 feature spec: split_frames tool, split→execute→synthesize pattern
- 3-agent review: architecture 7.0, implementation 6.5, research 7.5 (composite 7.0/10)
- 012.1 impl spec: 3-phase build plan (~10-13h total)
- V1 scope: inline synthesis, no recursive splits, max 5 sub-agents, 120s timeout
- Sub-agents always inherit censors, never get split_frames tool
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6fe98a9c93

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +296 to +299
session_id=session_id,
instruction=spec["task"],
subtask_type="frame_split",
frame_type=spec["frame_type"],
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Use actual Subtask field names in split handler

This constructor uses session_id and instruction, but the current Subtask ORM model (in nous/storage/models.py) defines parent_session_id and task and also requires agent_id; implementing this snippet as-is will fail at object construction and prevent any split_frames subtask from being created.

Useful? React with 👍 / 👎.

Comment on lines +302 to +305
metadata={
"context_hints": spec.get("context_hints", []),
"max_turns": spec.get("max_turns", 5),
},
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Use metadata_ instead of reserved metadata field

The proposed Subtask(...) payload sets metadata, but the mapped JSON column on Subtask is metadata_ (to avoid SQLAlchemy’s reserved metadata attribute); using metadata here will raise an invalid keyword error and break frame-split task creation.

Useful? React with 👍 / 👎.

start_time = datetime.utcnow()
futures = []
for task_id in subtask_ids:
future = await worker_pool.submit(task_id)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Define worker-pool submit API before awaiting futures

This flow assumes SubtaskWorkerPool.submit() returns awaitable futures, but the current worker pool implementation (checked nous/handlers/subtask_worker.py) only runs a dequeue loop and exposes no submit method; without documenting the required API change, the sync barrier design here is not implementable and would fail with AttributeError.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant