@troylar/sightline 1.177.0 → 1.181.2

package/docs/assistant-workflow.md

@@ -309,6 +309,23 @@ and never shows on hover cards. Anyone who can open the plan, and your assistant
 advice, never authorization: it can't approve a change or lower the review level. Set it with the item's `.set`
 action, field `aiHint`.
 
+### An outcome's priority
+
+`outcome.set` {id, field: class, why or reconsider, value, prev} sets an outcome's priority: `class` is `rock`
+(committed), `pebble` (supports a commitment), `sand` (if there's room) or blank, and `why` (why it matters) and
+`reconsider` (when to reconsider it) are one line each, up to 300 characters. A change to any of them always waits
+for a person, at every review level: the team's priority and its reason are a person's call. A plan with a class or
+either line needs this version or later: older copies open it read-only.
+
+### The work order
+
+`initiative.order` {ids} sets the team's work order: every initiative id, in the order the team will take them, and
+`[]` clears it. The forecast follows it when people are busy: ordered work gets people first, a nested initiative
+takes its nearest listed holder's place, and unordered work follows in workstream order, then by start. What an item
+waits for still comes first, and Jira-dated initiatives keep their sprint, so they can't be in the order. It always
+waits for a person, at every review level. The export has `planning.workOrder` and each initiative's `workOrder`
+place, from 1. A plan with a work order needs this version or later: older copies open it read-only.
+
 ### Workstream actions
 
 `workstream.set` {id, field: note, color, from or until, value, prev} and `workstream.move` {id, index} change a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@troylar/sightline",
-  "version": "1.177.0",
+  "version": "1.181.2",
   "description": "Your team's work, in plain sight. One HTML delivery planner, Jira context, and human-reviewed AI planning.",
   "license": "MIT",
   "keywords": [

package/skills/sightline-edit-plan/SKILL.md

@@ -24,6 +24,8 @@ Make the smallest coherent change that satisfies the request.
 - Check jiraLinked and datesFromTasks before proposing dates or status. Jira facts need a permitted Jira proposal; derived dates cannot be independently edited.
 - Keep logically dependent operations in one atomic change. Separate unrelated changes so the person can accept one without another.
 - For starts-after links, deletions, workstreams, people (role, allocation, workstream), milestones and what they're done after, gates, risks and decisions, holidays and time off, effort estimates (only numbers the person gives you) and what an initiative delivers, when people join and leave, how someone's time splits across workstreams, the support reserve, a workstream's note, color, dates and order (`workstream.set`, `workstream.move`; `workstream.del` only for an empty workstream, and it always waits for review; `workstream.reid {lane, id}` when a workstream's id no longer matches what it is, which also always waits for review: use the ids under `planning.workstreams`, and treat `was` as former ids, never as new ones), the skills catalog (`skill.add`, `skill.rename`, `skill.remove`, refused while a skill is in use), people's `skills` and work's `needs`, milestone stories, gate descriptions, meeting notes and `aiHint`, use the guide's action ops (`{op:"action", action, args}`) with the arguments listed under `actions`. Give every new item your own unique id, and put ops that depend on each other in one change, in order.
+- An outcome's priority (`class`: rock, pebble or sand; `why`; `reconsider`) is set with `outcome.set`, one line each, and always waits for a person at every review level. Change it only when the person asks.
+- The team's work order (`planning.workOrder`) is set with `initiative.order {ids}`: every initiative id, in order (`[]` clears it). Only when the person asks; it always waits for a person at every review level. Jira-dated initiatives aren't in it.
 - When the order of work is known but not its dates, add tasks with `after` (the tasks each starts after) and no `start`, and mark lengths you estimated with `rough: true`. To line up a task already in the plan, use `task.move` with `start: "after"`, never a delete and re-add: it keeps the task's ID and links. A task with `rough: false` in the context is set with `prev: false`.
 - For broad requests such as “move everything back,” show scope and affected IDs before generating changes. If something is in neither the guide's operations nor its actions, describe the manual UI path.
 

package/skills/sightline-plan-roadmap/SKILL.md

@@ -21,6 +21,8 @@ Translate the requested goals into outcomes the team can discuss.
 - Match existing outcomes by stable ID before proposing additions. Prefer an outcome describing a user or business result, with brief customer wording; distinguish a result from the tasks needed to achieve it.
 - Use the saved projectGuide and actual workstream IDs to suggest placement. Explain uncertain placements. Leave owners and timing unknown when the user has not supplied them; an idea can stay at idea stage without a date.
 - Preserve outcomes outside the requested window and call out any relevant ones. Calendar targets express planning intent; they do not establish team capacity or a delivery commitment.
+- An outcome's priority is the team's call. Propose a class (`rock` committed, `pebble` supports a commitment, `sand` if there's room) only when the person asks, always with a one-line `why`, through `outcome.set`; it always waits for a person. A class is importance, not size.
+- When the person asks for a work order, propose `initiative.order` with committed work first, and say why; it always waits for a person.
 - Propose only the changes the person requested. Put optional extra work in a separate suggestion, not in the proposal batch.
 
 Report the proposed quarter-by-quarter outcomes, material tradeoffs and the one missing decision that matters most. If a requested operation is absent from the current context guide, explain the UI step instead of inventing an operation.

package/skills/sightline-review-plan/SKILL.md

@@ -25,6 +25,8 @@ Review the requested scope, or the next four explicit calendar quarters when no
 - Missing or ambiguous owner, target or workstream information. Distinguish unknown from deliberately unassigned.
 - Unsupported timing or progress claims, especially Jira-derived status or dates. State snapshot freshness and omitted Jira coverage.
 - Dependencies, risks, capacity and decisions only where the supplied evidence supports them. The assistant view omits notes and may omit parts of the plan or Jira; do not claim to have reviewed missing data.
+- Priority gaps: a rock (`class: "rock"`) with no target, release or date recorded, or a class with no `why`. Point them out; never reclassify an outcome, since its class is the team's call.
+- Work order gaps: an initiative that delivers a rock but isn't in `planning.workOrder`, or sits after initiatives that only deliver sand. Point them out; never reorder, since the order is the team's call.
 - Relevant work outside the requested quarters. Do not recommend deleting it simply because the view excludes it.
 
 Lead with up to three material findings, naming stable IDs and the evidence behind each. End with focused next decisions. If no material issue is supported, say so and state the coverage limits. Offer proposed edits only if the person subsequently asks.