Jini
What Jini Shows
The shortest explanation of what Jini should keep visible while work is moving.
Jini should not make you guess.
While work is moving, the shell should keep the right context visible: the goal, the current inputs, the chosen route, the current step, what is already usable, and what still needs attention.
Keep The Work Legible
Show the goal, the active inputs, and any sibling work so the user always knows what thread they are in.
Keep The AI Choice Honest
Show the route, model, effort level, and why Jini chose them. If local routing matters, also show the device and runtime context behind that choice.
Keep Progress Concrete
Show what just finished, what is happening now, and what comes next instead of vague “thinking” language.
Keep Risk Visible
Show what is ready, what is missing, what is still uncertain, and whether the draft is still safe to review before anything is shared.
The Command That Matters
jini
That should be enough after install. From there, the user should be able to open ready work, see what is missing, or plan first without learning file paths or internal command names.
If more than one project is active, Jini should show Active work first, let the user pick one, and keep the rest visible as sibling work instead of hiding them behind the filesystem.
What Should Stay Visible
What am I working on?
Keep the goal, the current inputs, and any other active work visible so the user never loses the thread.
Goal · Working with · Other active work
Why is Jini using this AI stack?
Show the route, model, effort, and route reason. When Local SLM routing matters, also show the device class, local runtime, and accelerator context.
AI route · Model · Effort · Why this route
Where are we now?
Make progress readable in plain language by showing the latest completed step, the current step, and the next step.
Just finished · Doing now · Up next
What does Jini need from me?
Keep one active ask visible, explain why it matters, and show bounded ways to resolve it or defer it safely.
Need · Why this matters · Options · If you skip this
What can I use already?
Surface the deliverables that are already ready, the blockers that still matter, and any uncertainty Jini could not safely guess through.
Ready now · Blocked · Not sure about
Can I review safely?
Tell the user whether anything has already been sent or changed, so drafts can be reviewed before handoff.
Safe to do
What The Shell Should Feel Like
The shell should read like a working surface, not like a diagnostic panel.
Goal
Weekly product review follow-up
Working with
- Meeting notes.txt (processed)
- Hotel screenshot.png (attached)
AI route
Amazon Bedrock
How chosen
Automatic
Model
Claude Sonnet 4.6
Effort level
High
Why this route
Auto mode prefers the best planning tool when the request asks for deep or high-rigor work.
Just finished
- Sendable follow-up drafted
- Owners and due points pulled out
Doing now
Tightening owners, due dates, and open questions
Up next
Open Owners and Due Points
Need
Confirm any missing owner or due date before sending this follow-up.
Why this matters
The note is usable now, but it becomes truly sendable only when ownership and timing are explicit.
Options
- Add missing owner
- Add due date
- Skip for now
If you skip this
- Jini will keep the follow-up in draft form and leave missing owner or date gaps visible.
Ready now
- Sendable Follow-up
- Owners and Due Points
Blocked
- Owner confirmation
Not sure about
- Whether every action item has a clear owner
Safe to do
Nothing has been sent yet. You can review before sharing.
Other active work
- Pricing vendor review
- Paris trip
The important part is not only the provider name. The user should also be able to tell whether Jini chose that route automatically or because they forced it, and how much effort Jini judged the request to need before the first draft begins.
What “Show what's ready” Should Feel Like
It should open deliverables, not storage concepts.
Open useful work
The first thing the user sees should be the memo, checklist, follow-up, plan, or recommendation they can actually review.
Keep missing context nearby
Any blocker, uncertainty, or missing proof should stay visible next to the deliverable instead of being hidden in another command.
Make the next move obvious
The user should always know whether to review, clarify, approve, or continue, without learning Jini’s internal storage model.
Examples of the right shelf labels:
What Each Label Should Mean
Goal: the thing the user is trying to finish right nowWorking with: the visible inputs for the thread, including text, files, images, audio, or linksAI route: the tool and provider route Jini is using nowHow chosen: whether the route was automatic, user-locked, or a fallbackModel: the model Jini chose for this requestEffort level: how hard Jini judged the request to beWhy this route: the route policy or user choice behind the decisionJust finished: the durable changes from the latest turnDoing now: the current active step in plain wordsUp next: the next artifact or move Jini expects to takeNeed: the one highest-impact thing Jini still needsWhy this matters: why Jini is asking for that one thingOptions: the bounded ways the user can resolve the active askIf you skip this: the draft limits or assumptions Jini will preserve if the user does not answer yetReady now: things the user can open and use immediatelyBlocked: blockers that still materially matterNot sure about: uncertainty Jini could not safely guess throughSafe to do: whether anything has already been sent or changedOther active work: sibling projects the user can switch to without losing context