Example
How to run a coding-bootcamp capstone when the demo date cannot hold every feature
Anika's team does not need a longer feature backlog; it needs one user journey it can demonstrate and explain honestly.
AI assistance helped shape this fictional example from a structured editorial brief. It was reviewed for usefulness, distinctness, accessibility, and product truth.
Ship an honest capstone demo with one complete user journey, explainable technical choices, and no borrowed confidence
The honest user journey the team promises to demonstrate
Define one end-to-end journey as the finish line
Build work that protects that journey before the freeze
Choose whether live import is cut, contained, or stabilized
Keep the actual freeze clock beside the three import paths
Reproducible tests and working paths the team can show
Preserve the login path as tested working evidence
Turn the existing failure evidence into a limitation note the team can defend
Keep the prepared dataset as option evidence; freeze it only if the team records contain
Hold the scored rubric language used in the import decision
Hold the three reproducible failures that govern cut, contain, or stabilize
Handoffs and copy the team still owns before anyone else is waiting
Keep presentation copy with the teammate who owns it
Anika is an explicitly fictional portrait, not a customer or testimonial.
The Capstone demo Board gives one mission a visible field; the Cut, contain, or stabilize live import Room keeps its evidence, conversation, state, and decision together.
Current You.one provides the Superboard structure and explicit, bounded Ava paths described here; broader proactive or external work is not a current promise.
Why Capstone demo needs an operating picture
Anika is a fictional 27-year-old career-switcher finishing a part-time coding bootcamp in Seattle, Washington. Anika's team has ten days, a working login, an unreliable data import, and four polished feature ideas. The rubric rewards a coherent demonstration, not the longest backlog.
The login path already works. An unstable import can still erase the only user journey the team can demonstrate end to end.
The rubric, failure cases, and remaining integration day have to govern the cut—not whichever feature is most exciting to polish.
In You.one's Superboard view, Anika can give “Ship an honest capstone demo with one complete user journey, explainable technical choices, and no borrowed confidence” a Board of its own. That Board connects requirements, practice or work evidence, deadlines, and accountable human judgment; opening “Cut, contain, or stabilize live import” creates a Room for its evidence, discussion, state, and decision.
The demo needs one reliable journey, not ten hopeful features
The mission is specific: Ship an honest capstone demo with one complete user journey, explainable technical choices, and no borrowed confidence.
The consequential choice is not something a board or an AI should quietly make: Whether to cut live import, contain it behind a prepared dataset, or spend the remaining integration day stabilizing it.
You.one can keep the work, evidence, and “Cut, contain, or stabilize live import” decision visible through its Superboard view. The Owner boundary stays explicit: Anika and her teammates own the code, attribution, testing, scope, and every claim made in the demo.
Available today
Capstone demo: one Board shape to adapt
The Capstone demo Board gives this mission one durable operating picture. Anika can use familiar language instead of translating the situation into project-management jargon. Its four Lists separate the kinds of attention this situation actually requires.
Its Cards deliberately distinguish actions, evidence, and decisions while keeping unsent questions in owned work. A Waiting List would be premature until a named request or outside condition is actually in motion. That separation makes the current choice, evidence, and next move easier to scan.
| List | What belongs here |
|---|---|
| Demo promise | The honest user journey the team promises to demonstrate |
| Build next | Build work that protects that journey before the freeze |
| Working evidence | Reproducible tests and working paths the team can show |
| Team handoffs | Handoffs and copy the team still owns before anyone else is waiting |
Available today
The Cards make the operating picture concrete
These Card titles come directly from Anika's situation: “Cut, contain, or stabilize live import” is the live choice, “Login path works” holds evidence, and “Draft the presentation-copy handoff” is still work Anika controls—not a fake Waiting item. The point is recognition, not a perfect taxonomy.
| Card | List | Job |
|---|---|---|
| One journey that works end to end | Demo promise | Define one end-to-end journey as the finish line |
| Cut, contain, or stabilize live import | Build next | Choose whether live import is cut, contained, or stabilized |
| Login path works | Working evidence | Preserve the login path as tested working evidence |
| Draft the import limitation note | Working evidence | Turn the existing failure evidence into a limitation note the team can defend |
| Draft the presentation-copy handoff | Team handoffs | Keep presentation copy with the teammate who owns it |
| Dataset we could freeze if contain is chosen | Working evidence | Keep the prepared dataset as option evidence; freeze it only if the team records contain |
| Demo rubric: coherent journey over feature count | Working evidence | Hold the scored rubric language used in the import decision |
| Ten days to demo; one integration day remains | Build next | Keep the actual freeze clock beside the three import paths |
| Import failure cases | Working evidence | Hold the three reproducible failures that govern cut, contain, or stabilize |
Available today
Available today: Cut, contain, or stabilize live import becomes a Room
Opening the Card gives the visible item durable depth. Stage can hold Import decision note: Place “Demo rubric: coherent journey over feature count,” “Import failure cases,” “Ten days to demo; one integration day remains,” “Dataset we could freeze if contain is chosen,” and “Login path works” together. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Anika and her teammates will choose whether to cut, contain, or stabilize live import.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Import decision note and this Card Room's visible notes and left “Cut, contain, or stabilize live import” with Anika and her teammates.”
A useful Card Chat request would be: “Using “Demo rubric: coherent journey over feature count,” “Import failure cases,” “Ten days to demo; one integration day remains,” “Dataset we could freeze if contain is chosen,” and “Login path works,” compare cutting live import, containing it behind a prepared dataset, and stabilizing it in the remaining integration day. Cite the evidence and leave scope, code, and demo choices to the team.” When live AI is configured, current Ava can respond to an explicit Card mention using supported Room context and can make limited reversible changes inside this Card Room after an explicit request. She uses only supported Room context; she cannot summarize the Board, watch other Lists, or act outside this Card Room. She does not gain authority over the decision merely because the context is organized.
Anika's call remains explicit: Anika and her teammates own the code, attribution, testing, scope, and every claim made in the demo.
| Surface | Job in this example |
|---|---|
| Stage | Import decision note: Place “Demo rubric: coherent journey over feature count,” “Import failure cases,” “Ten days to demo; one integration day remains,” “Dataset we could freeze if contain is chosen,” and “Login path works” together |
| Chat | Keep Anika's request and Ava's attributed response with the work |
| Pulse | Open decision: Anika and her teammates will choose whether to cut, contain, or stabilize live import |
| Activity | Ava compared the options in Card Chat using the Import decision note and this Card Room's visible notes and left “Cut, contain, or stabilize live import” with Anika and her teammates |
What to ask Ava—and what not to assume
These requests use the visible supported context inside the “Cut, contain, or stabilize live import” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Anika must provide the relevant facts and check the result.
Current Ava can reply in this Room to an explicit Card mention using supported Room context. She cannot summarize the Board, make the choice, represent Anika, watch other Lists, or act outside this Card Room.
Anika and her teammates own the code, attribution, rubric interpretation, and demo. Ava does not write assessed work or fabricate tests.
The team has a demoable spine and a truthful explanation of what was cut, contained, and learned.
- Request idea: using “Demo rubric: coherent journey over feature count,” “Import failure cases,” “Ten days to demo; one integration day remains,” “Dataset we could freeze if contain is chosen,” and “Login path works,” compare cutting live import, containing it behind a prepared dataset, and stabilizing it in the remaining integration day. Cite the evidence and leave scope, code, and demo choices to the team.
- Request idea: use only the Import decision note and notes the Owner has placed in this Card Room to separate facts, assumptions, and unanswered questions
- Request idea: name which visible Room note could most change the comparison; do not watch other Lists or follow up autonomously
A shared feature checklist may still be enough
A shared feature checklist is enough when features are independent and no failure can erase the demo path.
It starts to break when one unstable technical choice can erase the whole demonstration.
The Capstone demo Board earns its place only when the familiar tool—a shared feature checklist—can no longer keep the reason, Import decision note, conversation, current state, decision, and history connected.
A starter recipe to adapt, not obey
Anika should rename every List or Card that feels artificial. This recipe succeeds when “Cut, contain, or stabilize live import” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.
| Step | Action |
|---|---|
| 1. Name the journey | Write the one user path the demo must complete |
| 2. Reproduce the risk | Record three import failures before debating features |
| 3. Read the rubric | Separate scored coherence from backlog ambition |
| 4. Record the import call | Open one Room, compare cut, contain, or stabilize, and record exactly one path |
| 5. Cut, contain, or stabilize live import | Freeze a prepared dataset only after contain is chosen; otherwise cut or stabilize as recorded and document the truthful limit |
Direction
Direction, not a current promise
A future Ava may flag when a new failure invalidates the frozen demo path. The team would still decide scope, write the code, test it, and present it.
A future unified You.one experience could carry relevant context from “Cut, contain, or stabilize live import” across guidance and the Superboard view. Broad proactive coordination, cross-surface personalized memory, realtime shared editing, and general external execution are not available today. Any future action would still require the applicable capability, connection, grant, and human authority.
What this realistic example does not claim
- Anika is fictional and is not a customer, testimonial, research participant, or disguised real person.
- This is not a claim that AI completed or evaluated a student capstone.
- It does not show Ava completing external actions or contacting anyone for Anika.
- It does not report a measured result, and this Board is a starting shape to adapt—not a universal prescription.