diff --git a/docs/changelog-add-followup.md b/docs/changelog-add-followup.md deleted file mode 100644 index b879630..0000000 --- a/docs/changelog-add-followup.md +++ /dev/null @@ -1,36 +0,0 @@ -# Session persistence and followup commands - -## Implemented session persistence - -Add a BlogSession model containing a stable session ID, timestamps, and the completed ResearchState. Keep ResearchState as the workflow payload rather than duplicating its draft, research, review, and revision fields. - -Add an IBlogSessionStore abstraction with CreateAsync, GetAsync, and SaveAsync, plus a local file-backed implementation for the console app. Store sessions under a configurable application-data directory; avoid hosted-agent instance memory because deployments can restart or scale. - -Update Program.cs into a small command loop: - -New topic: create a session and run the workflow. -Follow-up: accept a session ID and a user request such as “make it shorter” or “add a section on caching.” -Load the prior state, reset only workflow-control fields needed for a fresh revision cycle, append the follow-up to CurrentSubTask, then rerun the existing workflow. -Define continuation semantics in ResearchState: - -Preserve MainTask, ResearchFindings, and Draft. -Clear ReviewNotes. -Reset RevisionNumber to 0 so each user-requested revision receives its own bounded review cycle. -Record the follow-up instruction explicitly, rather than silently altering the original topic. -Update the Author and Reviewer prompts to recognize a continuation request and revise the prior draft using the stored research, while retaining the existing APPROVED contract and two-pass revision limit. - -Add tests for session serialization/lookup, missing or expired session IDs, and a follow-up state transition proving the draft and research persist while review-cycle fields reset. Keep the existing workflow tests unchanged except for any deliberate continuation-specific additions. - -Add configuration and documentation for BLOG_SESSION_STORE_PATH, retention behavior, and the CLI interaction. For a production/multi-machine console deployment, replace the file store with a durable shared store such as Azure Blob Storage or Cosmos DB behind the same interface. - -## Implemented persistent follow-up sessions. - -The console now saves each workflow result as JSON under %LOCALAPPDATA%\BlogWriter\sessions by default. It prints the session ID after each run, accepts follow-up revision requests immediately, and supports resume after restarting the app. - -Key changes: - -Added BlogSession.cs, IBlogSessionStore.cs, and FileBlogSessionStore.cs. -Added ResearchState.StartFollowUp() to preserve the draft/research and reset the review cycle. -Updated Program.cs for new, follow-up, and resumed sessions. -Passed follow-up instructions to the Author agent and synchronized AgentPrompt.cs. -Documented BLOG_SESSION_STORE_PATH and resume behavior. \ No newline at end of file diff --git a/docs/changelog-move-to-foundry.md b/docs/changelog-move-to-foundry.md deleted file mode 100644 index 627804a..0000000 --- a/docs/changelog-move-to-foundry.md +++ /dev/null @@ -1,53 +0,0 @@ -# Changelog: v1 → current (hosted agents) - -This summarizes what changed in the `hostedAgents` branch versus the original -in-process version of BlogWriter, for anyone picking the project back up. - -## 1. Agents moved from in-process to independently deployed Foundry Hosted Agents - -**Before:** Blogger/Researcher/Author/Reviewer were built and run in-process inside the -console app. - -**Now:** each agent is its own project under `HostedAgents//`, deployed -independently via `azd` to Azure AI Foundry Agent Service, with its own compute, -Entra ID identity, and OpenAI-compatible `/responses` endpoint. The console app only -references them by name (`AsAIAgent(agentEndpoint, ...)`) — it never builds, provisions, -or updates them at runtime. See [architecture.md](architecture.md). - -## 2. Researcher's web search moved from a custom Tavily tool to Foundry-native `HostedWebSearchTool` - -**Before:** the Researcher agent called a custom Tavily HTTP function/tool with a -hand-written function schema. This schema was incompatible with the hosted Responses -endpoint and caused HTTP 400 failures during the migration to hosted agents. - -**Now:** the Researcher hosted agent uses Foundry's built-in `HostedWebSearchTool()` -(see `HostedAgents/Researcher/Program.cs`). Search executes server-side inside the -hosted agent process; there's no Tavily API key or custom tool schema to maintain. - -## 3. Per-call token limit replaced with a shared, cumulative token budget - -**Before:** a per-call `MAX_OUTPUT_TOKENS` request option was sent on every model call. -This option isn't supported by the Foundry Hosted Agent Responses endpoints and was -dead weight even before that. - -**Now:** `TokenCapChatClient.CreateSharedFactory(maxTotalTokens)` wraps all four agents -via MAF's `clientFactory` hook, tracking one cumulative token count across the whole -workflow run (`MAX_TOTAL_TOKENS`, default 40,000). Exceeding it throws -`TokenCapExceededException` and the app shuts down gracefully instead of continuing to -spend tokens. - -## 4. All agent connectivity now goes through Microsoft Agent Framework — never raw HTTP - -**Before/during migration:** there was a temptation (and at one point, an attempt) to -call agent endpoints directly over HTTP. - -**Now:** every agent call is `AIProjectClient.AsAIAgent(...)` + `AIAgent.RunAsync(...)`. -This is enforced as a hard constraint in `AGENTS.md`/MAF Doctor guidance, not just a -style preference — direct HTTP calls to agent endpoints should be treated as a bug if -seen again. - -## Known limitation carried forward - -The original README's "Known Issues" note — more LLM calls than expected per run, -possibly a telemetry over-count rather than a real issue — is still open. See -[architecture.md](architecture.md#known-limitation).