Scout foundation — trace one attributed source through the shared agent task #155

Outcome

Kiran leads the integration foundation for one useful source-to-answer task and its Graph/Altar handoff, starting with the existing Scout mechanisms.

Selection: first important side quest after the shared web/phone main work in #154/#159. Keep in Backlog until a bounded slot is selected; this preserves the full study below without another simultaneous subsystem commitment.

Primary: Kiran (@Kiranchaudhary537)
Partner: Chirayu (@ChirayuBatra99) — user journey, agent result acceptance and independent reproduction.
Technical support: Anshuk (@geeked-anshuk666) can compare the framework mechanisms he has studied, existing Scout contracts and reuse/provenance requirements. This is bounded help, not shared primary ownership.
Shared outcome: #132. Full acquisition acceptance: #43; broader search/RSS/custody remain with #62, #98 and #23.

First result

• Select one bounded public-page scene with Chirayu and name its Composition/agent purpose. Trace declared URL and authorization → separate Fetch/Extract effects → attributed transient material → Graph continuation → useful answer and visible source.
• Inspect the current source and evidence through State of Work. Explain the difference between component receipts, durable worker/persistence tests and the still-required combined deployment passage; do not rebuild existing fetch/extract machinery.
• Demonstrate a bounded fixture or reproduction with useful output, attribution and one refusal/interruption/unknown case. Explain why lost transient material does not authorize an automatic refetch.
• Agree the typed integration and request/result seam with Chirayu and Enter — design one request/result passage from Discord to the founder PC #131. Identify which state is retained and how UI distinguishes acquisition, agent completion and acceptance of the result.
• Review the seam before expanding adapters. Propose one missing acceptance passage or narrow repair and give another developer runnable steps or an exact environmental blocker.
• Record the next integration direction: GitHub Reach Reach side quest — prove one GitHub conversation read and the provider boundary #160 before Gmail, with YouTube later. Keep each account/authorization/delivery contract separate from Scout.

Scope

When selected, this is a small Scout foundation study within #132. It does not start the whole #43 implementation or move every retained acquisition outcome out of Later. Search, multi-page crawling, browser rendering and raw-download retention need separately selected scope.

When learning from another project, name the exact mechanism, revision, receiving owner, applicable terms and required notices before incorporation; use the repository reuse procedure. A new browser framework is not the default first step.

Working method

Understand the existing foundations and review any proposed shared-contract changes before multiplying implementations. Use coding agents for investigation, bounded prototypes, implementation and independent challenge. A small prototype can run alongside design and inform it; it must identify fixtures and assumptions. After the representative path and its reusable pattern are understood, build quickly within those boundaries.

The primary coordinates this result; the partner helps design, reviews the explanation and reproduces the example. Others may contribute or propose a different approach. The author reviews the full generated diff. Founder architecture/code approval and CONTRIBUTING remain in force. Bring one concise evidence packet: demo/trace, changed contracts, failure observations, checks and the next decision.

Checkpoint: the next shared planning/demo after the first reproduction. This is one bounded foundation result, not completion of the larger linked capabilities. Keep at most one review-ready implementation slice per pair awaiting the founder.