Inspiration
Small teams need to understand what is waiting, choose a useful next move, and remember the decision. Projects Briefing connects a short conversation with the work itself while preserving human control over changes.
What it does
Ask, “What can we move forward today?” The companion reads six fictional work items with owners, blockers, next actions, and completion criteria. It explains the work and can propose a change. A before/after card shows exactly what would change. The person confirms or cancels; saved decisions appear in history and shape the next briefing. Saving a next action does not mark work complete.
This is an explicitly labeled Alexa+ simulation with typed conversation. It does not connect to Alexa+ preview services or production Projects data.
How we built it
The Svelte 5/Vite interface uses public MIT-licensed Wornpage components. A Node.js 24 server stores the isolated demo workspace, proposals, history, and inference receipts in SQLite. Amazon Nova Micro runs through Amazon Bedrock Converse in us-east-1. The conversation executes three tools through a real Streamable HTTP MCP client and server using protocol 2025-11-25: get_briefing, get_work_item, and propose_next_action.
The model can read and propose. Human confirmation uses a separate HttpOnly browser credential and checks the source workspace revision. Confirmation applies once, stale proposals are rejected, and workspaces are isolated by browser ownership.
Challenges and lessons
An earlier model request described a proposal without creating a tool result. The interface treats the actual saved proposal as authoritative: prose alone never grants confirmation or changes an item. A later failed lookup used a title instead of an item ID; enumerating exact IDs in the tool schema corrected that demonstrated case. Provider failures and uncertain usage remain in the cost ledger.
We learned that a helpful conversation needs a clear path back to the work, readable before/after evidence, and a distinct human decision. The interface now puts work first, with separate Needs review and Decisions views and deliberate keyboard focus.
What we verified
A fresh source checkout installed and built successfully, and all 57 local tests passed. They cover HTTP MCP, confirmation, cancellation, stale and duplicate actions, persistence, isolated demos, and keyboard interaction. Actual Bedrock validation demonstrated briefing, proposal, human confirmation, refresh, and an updated briefing.
The 80-second demo shows retained actual Bedrock results with English captions. It captures an earlier interface; the source includes later work/review navigation improvements. The video does not perform new inference or reenact a confirmation. Automated fixtures prove application behavior, not general model reliability.
AWS Builder integration
Amazon Bedrock Converse invokes amazon.nova-micro-v1:0 through the AWS SDK for JavaScript v3 and a dedicated AWS profile. The Node server executes the model's requested tools through an MCP client. Output is limited to 800 tokens per call, automatic retries are disabled, and token receipts and the test allowance persist across restarts.
What is new and what is next
This standalone app, Bedrock conversation, MCP tools, confirmation boundary, local persistence, and demo interface were independently authored during the challenge. It shares public Wornpage components and general product ideas with Projects; it contains no production Projects or Nebius edition source.
Next steps are broader evaluation of model tool selection, voice interaction, and an explicitly authorized connection to real customer workspaces. The current version stays focused on typed conversation and reviewed work decisions.
Run it and read the feedback
The public MIT-licensed repository includes setup instructions, tests, and the v0.1.0 source release. It runs locally with Node.js 24 and a reviewer-owned AWS profile. Product feedback and friction logs are in docs/product-feedback.md.
Log in or sign up for Devpost to join the conversation.