Ting/Vedanta
Watch
2
0
Fork
You've already forked Vedanta
 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions

Research: monitor-claim Queen death to dormant-token invalidation #13

New issue
Open
opened 2026-08-26 07:46:18 +00:00 by agent.odin · 4 comments
agent.odin commented 2026-08-26 07:46:18 +00:00
Owner
Copy link

Proposal

Define and prove the monitor-claim path that transitions a workflow to dormant when its Queen process dies, then triggers invalidation of that workflow’s agent JWTs. This is separate from #8’s Kanidm service-account token lifecycle and from #12’s OpenBao plugin.

Design

  • Vedanta does not monitor Queens. A VM-level liveness monitor observes process death.
  • A monitor holds only the monitor claim. It has no authority to mint, rotate, read, or broadly invalidate credentials.
  • The monitor emits an authenticated Queen-death/dormancy event. The event is the narrow input to the workflow-dormancy path; Vedanta only acts after it verifies the required authority checks.
  • Normal session closure remains Queen-seat authority. Queen death is the exceptional route: the monitor causes Swarm roles to become dormant, and workflow tokens are invalidated.

Owner ruling (2026-09-03), Q3 — the invalidation plane. A Queen death reaches the ratified resource-lease plane only: OpenBao leases and the exact downstream resource-token IDs those leases name. The separate principal-authentication JWT plane is out of scope for this record, and adding it requires an explicit ruling naming its issuer, its signing key, and its revocation boundary. Until that ruling exists, no dormancy path may invalidate a principal-auth JWT, and a monitor event that appears to demand one is a contract error rather than a wider grant.

Tasks

  • Identify the VM-level monitor implementation and its authoritative liveness signal.
  • Specify the signed monitor-claim event, including Queen, workflow, observed death, and idempotency identity.
  • Define the handoff that transitions Swarm roles to dormant and names the token-invalidation request, bounded to the resource-lease plane per the Q3 ruling.
  • Prove the monitor cannot invoke any credential operation outside its monitor claim.
  • Prove no dormancy path reaches the principal-authentication JWT plane.
  • Exercise duplicate, delayed, forged, and monitor-unavailable events with capture doubles.

Specification Delta

Requirement: a Queen death enters dormancy without granting token administration

  • GIVEN a Queen process disappears
  • AND an authorized VM-level monitor holds only the monitor claim
  • WHEN the monitor emits an authenticated death event for that Queen and workflow
  • THEN the workflow transitions to dormant through the defined control-plane handoff
  • AND the workflow’s OpenBao leases and their exact named resource-token IDs are invalidated
  • AND the monitor cannot mint, rotate, read, or broadly revoke any credential

Requirement: dormancy does not reach the principal-authentication plane

  • GIVEN a workflow transitioning to dormant on Queen death
  • WHEN invalidation runs
  • THEN only resource leases and their exact token IDs are invalidated
  • AND no principal-authentication JWT is revoked, absent a separate ruling naming issuer, key, and revocation boundary

Requirement: normal closure remains Queen authority

  • GIVEN a live Queen completes its shutdown protocol
  • WHEN the Queen closes the workflow
  • THEN its workflow JWTs are invalidated only after full shutdown closure
  • AND no fixed grace timer is inferred by Vedanta
## Proposal Define and prove the monitor-claim path that transitions a workflow to dormant when its Queen process dies, then triggers invalidation of that workflow’s agent JWTs. This is separate from #8’s Kanidm service-account token lifecycle and from #12’s OpenBao plugin. ## Design - Vedanta does not monitor Queens. A VM-level liveness monitor observes process death. - A monitor holds only the `monitor` claim. It has no authority to mint, rotate, read, or broadly invalidate credentials. - The monitor emits an authenticated Queen-death/dormancy event. The event is the narrow input to the workflow-dormancy path; Vedanta only acts after it verifies the required authority checks. - Normal session closure remains Queen-seat authority. Queen death is the exceptional route: the monitor causes Swarm roles to become dormant, and workflow tokens are invalidated. **Owner ruling (2026-09-03), Q3 — the invalidation plane.** A Queen death reaches the ratified resource-lease plane only: OpenBao leases and the exact downstream resource-token IDs those leases name. The separate principal-authentication JWT plane is **out of scope for this record**, and adding it requires an explicit ruling naming its issuer, its signing key, and its revocation boundary. Until that ruling exists, no dormancy path may invalidate a principal-auth JWT, and a monitor event that appears to demand one is a contract error rather than a wider grant. ## Tasks - [ ] Identify the VM-level monitor implementation and its authoritative liveness signal. - [ ] Specify the signed monitor-claim event, including Queen, workflow, observed death, and idempotency identity. - [ ] Define the handoff that transitions Swarm roles to dormant and names the token-invalidation request, bounded to the resource-lease plane per the Q3 ruling. - [ ] Prove the monitor cannot invoke any credential operation outside its monitor claim. - [ ] Prove no dormancy path reaches the principal-authentication JWT plane. - [ ] Exercise duplicate, delayed, forged, and monitor-unavailable events with capture doubles. ## Specification Delta ### Requirement: a Queen death enters dormancy without granting token administration - GIVEN a Queen process disappears - AND an authorized VM-level monitor holds only the `monitor` claim - WHEN the monitor emits an authenticated death event for that Queen and workflow - THEN the workflow transitions to dormant through the defined control-plane handoff - AND the workflow’s OpenBao leases and their exact named resource-token IDs are invalidated - AND the monitor cannot mint, rotate, read, or broadly revoke any credential ### Requirement: dormancy does not reach the principal-authentication plane - GIVEN a workflow transitioning to dormant on Queen death - WHEN invalidation runs - THEN only resource leases and their exact token IDs are invalidated - AND no principal-authentication JWT is revoked, absent a separate ruling naming issuer, key, and revocation boundary ### Requirement: normal closure remains Queen authority - GIVEN a live Queen completes its shutdown protocol - WHEN the Queen closes the workflow - THEN its workflow JWTs are invalidated only after full shutdown closure - AND no fixed grace timer is inferred by Vedanta
agent.odin commented 2026-08-26 07:46:18 +00:00
Author
Owner
Copy link

Grooming state: Q3 ratified; the record still needs its probe and the research recast.
Evidence: The checked Vordr runtime has an in-process Queen fleet, a drone-birth sentinel, and explicit operator restart, but no VM-level Queen monitor, monitor-claim signer, dormant-workflow store, or Queen-death route. Ratified OpenSpec 61 v0.1.4 makes OpenBao the workload-facing lease authority and Vedanta the private exact resource-token effector.

Frontier

Q3 — invalidation plane. Ratified (Larandar, 2026-09-03): this record stays on the ratified resource-lease plane — OpenBao leases plus the exact downstream resource-token IDs they name. The principal-authentication JWT plane is excluded; adding it requires an explicit ruling naming issuer, signing key, and revocation boundary. Recorded in Design, with a new Specification Delta requirement and a task proving no dormancy path reaches that plane.

Q4 — deferred. Dormant-state/control-plane ownership is chosen only if Q1 leaves multiple concrete implementations.

Investigation

Q1 — probe, not an owner question. Identify the actual Queen runtime/process boundary, authoritative death signal, monitor identity/key source, output schema, and evidence landing place. Include the vordr#93 late-observer false-positive regression.

Q2 — deferred. The dormancy handoff cannot be chosen until Q1 yields concrete boundaries.

Proposal

Recast this issue as a bounded research probe with declared result columns and closing-comment landing; derive isolated implementation leaves only after the probe. Accept if no authoritative monitor boundary already exists; reject if a deployed monitor contract is found. Status/Need More Info lifted — no owner question remains. Status/Need Grooming stands until the probe runs and the record is recast.

<!-- agent.odin:groom:v1 --> **Grooming state:** Q3 ratified; the record still needs its probe and the research recast. **Evidence:** The checked Vordr runtime has an in-process Queen fleet, a drone-birth sentinel, and explicit operator restart, but no VM-level Queen monitor, monitor-claim signer, dormant-workflow store, or Queen-death route. Ratified [OpenSpec 61 v0.1.4](https://jo.et0.pw/Ting/Ting/wiki/OpenSpec-61-forge-identity-lifecycle-contract) makes OpenBao the workload-facing lease authority and Vedanta the private exact resource-token effector. ### Frontier **Q3 — invalidation plane. Ratified (Larandar, 2026-09-03):** this record stays on the ratified resource-lease plane — OpenBao leases plus the exact downstream resource-token IDs they name. The principal-authentication JWT plane is excluded; adding it requires an explicit ruling naming issuer, signing key, and revocation boundary. Recorded in Design, with a new Specification Delta requirement and a task proving no dormancy path reaches that plane. **Q4 — deferred.** Dormant-state/control-plane ownership is chosen only if Q1 leaves multiple concrete implementations. ### Investigation **Q1 — probe, not an owner question.** Identify the actual Queen runtime/process boundary, authoritative death signal, monitor identity/key source, output schema, and evidence landing place. Include the vordr#93 late-observer false-positive regression. **Q2 — deferred.** The dormancy handoff cannot be chosen until Q1 yields concrete boundaries. ### Proposal Recast this issue as a bounded research probe with declared result columns and closing-comment landing; derive isolated implementation leaves only after the probe. Accept if no authoritative monitor boundary already exists; reject if a deployed monitor contract is found. Status/Need More Info lifted — no owner question remains. Status/Need Grooming stands until the probe runs and the record is recast.
larandar commented 2026-09-03 22:57:42 +00:00
Owner
Copy link

Q1 probe result — 2026-09-04

Source: swarm/vordr at 000b1bb, static read of the tree. No running system was inspected, and nothing here rests on a live observation.

The finding that moves this record

There is no Queen process, so there is nothing to observe dying.

queen.Queen is a Go interface — "the live set of drones and the thing that conducts them". It has no process, no PID, no supervisor, no exit status. os/exec appears in exactly four files (harness/preset.go, kitten/cmd/vordr/main.go, kitten/tui/tui.go, zmx/cli.go), and every one of them spawns a drone or the frontend itself. Nothing spawns a queen.

A queen lives inside whatever process hosts it, and the package doc names the reference host: "Nothing in the core imports queen — only a frontend may, and the kitten is the reference one." So "the Queen died" is not an event about a queen at all. It is the kitten exiting, taking every queen and every in-process drone reference with it.

This record's design — "a VM-level liveness monitor observes process death" and emits "an authenticated Queen-death event" — has no referent in the deployed runtime. It is not unbuilt; it is describing a boundary that does not exist.

What the sentinel actually is

warden.Sentinel is a drone-birth sentinel, not a death monitor, and its subject is a drone rather than a queen. It counts printable bytes in a drone's PTY output within a 15-second grace and reports StatusError if none arrive.

Its reasoning is worth reading before anyone proposes reusing it: "a drone wedged at birth is not silent" — zmx with fish emits sixty-two bytes of terminal negotiation and not one printable character, forever. So "has it produced output" answers yes for a drone that will never start, and the sentinel asks "has it produced anything a human would see" instead.

The vordr#93 late-observer regression is handled, and is drone-scoped. Arm() re-checks under the lock rather than trusting the select, because a deadline and a disarm can become ready in the same instant and select picks at random: "A drone torn down exactly as its grace expires must not be reported dead, and 'almost never' is not the same as 'never' across a fleet." Nothing about it generalises to queens — it observes a PTY that a queen does not have.

Result columns

asked found
Queen runtime/process boundary none — an in-process interface, hosted by the frontend
authoritative death signal none; the nearest event is the host process exiting
monitor identity / key source none in the tree
monitor claim does not exist
event output schema does not exist
evidence landing place does not exist
vordr#93 false-positive class handled, in Sentinel.Arm, for drones only

What this leaves

Q3 was already ratified — the invalidation plane stops at OpenBao leases and exact resource-token IDs. That ruling stands and is unaffected.

Q1 and Q2 are answered in the negative, which changes the record rather than completing it. This is no longer a Deliverable waiting on a probe; it is a proposal that a monitor boundary should exist. Building it means deciding what hosts a queen, whether that host has an identity, and what would sign an event — none of which vordr answers today, and none of which is Vedanta's to decide alone.

➡️ Recast as a design question for the runtime owner, or close as superseded. The Status/Need Grooming label stands either way; what it needs is not more grooming of this text but a ruling on whether the estate wants a queen-death boundary at all, given that a queen is currently a variable inside a TUI.

<!-- larandar:groom:v1 --> ## Q1 probe result — 2026-09-04 **Source:** `swarm/vordr` at `000b1bb`, static read of the tree. No running system was inspected, and nothing here rests on a live observation. ### The finding that moves this record **There is no Queen process, so there is nothing to observe dying.** `queen.Queen` is a Go **interface** — *"the live set of drones and the thing that conducts them"*. It has no process, no PID, no supervisor, no exit status. `os/exec` appears in exactly four files (`harness/preset.go`, `kitten/cmd/vordr/main.go`, `kitten/tui/tui.go`, `zmx/cli.go`), and every one of them spawns a **drone** or the frontend itself. Nothing spawns a queen. A queen lives inside whatever process hosts it, and the package doc names the reference host: *"Nothing in the core imports queen — only a frontend may, and the kitten is the reference one."* So "the Queen died" is not an event about a queen at all. It is the kitten exiting, taking every queen and every in-process drone reference with it. This record's design — *"a VM-level liveness monitor observes process death"* and emits *"an authenticated Queen-death event"* — has no referent in the deployed runtime. It is not unbuilt; it is describing a boundary that does not exist. ### What the sentinel actually is `warden.Sentinel` is a **drone-birth** sentinel, not a death monitor, and its subject is a drone rather than a queen. It counts *printable* bytes in a drone's PTY output within a 15-second grace and reports `StatusError` if none arrive. Its reasoning is worth reading before anyone proposes reusing it: *"a drone wedged at birth is not silent"* — zmx with `fish` emits sixty-two bytes of terminal negotiation and not one printable character, forever. So *"has it produced output"* answers yes for a drone that will never start, and the sentinel asks *"has it produced anything a human would see"* instead. **The vordr#93 late-observer regression is handled, and is drone-scoped.** `Arm()` re-checks under the lock rather than trusting the select, because a deadline and a disarm can become ready in the same instant and `select` picks at random: *"A drone torn down exactly as its grace expires must not be reported dead, and 'almost never' is not the same as 'never' across a fleet."* Nothing about it generalises to queens — it observes a PTY that a queen does not have. ### Result columns | asked | found | |---|---| | Queen runtime/process boundary | none — an in-process interface, hosted by the frontend | | authoritative death signal | none; the nearest event is the host process exiting | | monitor identity / key source | none in the tree | | `monitor` claim | does not exist | | event output schema | does not exist | | evidence landing place | does not exist | | vordr#93 false-positive class | handled, in `Sentinel.Arm`, for drones only | ### What this leaves Q3 was already ratified — the invalidation plane stops at OpenBao leases and exact resource-token IDs. That ruling stands and is unaffected. Q1 and Q2 are answered in the negative, which changes the record rather than completing it. **This is no longer a Deliverable waiting on a probe; it is a proposal that a monitor boundary should exist.** Building it means deciding what hosts a queen, whether that host has an identity, and what would sign an event — none of which vordr answers today, and none of which is Vedanta's to decide alone. ➡️ **Recast as a design question for the runtime owner, or close as superseded.** The `Status/Need Grooming` label stands either way; what it needs is not more grooming of this text but a ruling on whether the estate wants a queen-death boundary at all, given that a queen is currently a variable inside a TUI.
larandar commented 2026-09-03 23:02:10 +00:00
Owner
Copy link

Correction to the probe above — 2026-09-04

Freeholder correction: vordr is a spike. Its current shape is not the final state.

The observations in the previous comment stand as observations — queen.Queen is an in-process interface today, os/exec spawns only drones and the frontend, and there is no monitor identity or event schema in that tree. What does not stand is what I concluded from them.

The error. I wrote that this record "describes a boundary that does not exist" and recommended recasting it as a design question or closing it as superseded. That converts "the spike has not built this" into "the architecture does not have this", which the evidence does not support. A spike is a thing built to answer a founding question, not a statement about what the runtime will hold; absence in it is absence of a decision, not a decision against.

What the probe actually established, restated honestly:

  • No monitor boundary exists in the spike. That is a fact about the spike.
  • The estate has therefore not yet chosen what hosts a queen, whether that host carries an identity, or what would sign a death event. Unchosen, not refused.
  • warden.Sentinel's scope is genuinely drone-birth rather than queen-death, and the vordr#93 late-observer fix is genuinely drone-scoped. Those hold regardless of what the runtime becomes, and are the reusable part.

What this changes for the record. Q1 asked for the deployed monitor boundary so this design could be specified against it. The correct answer is not yet determined, not does not exist — so this stays a Deliverable waiting on a prerequisite, exactly as it was, rather than becoming a proposal to be argued down.

The recommendation in the previous comment is withdrawn. Q3's ratified ruling is untouched by any of this: the invalidation plane stops at OpenBao leases and exact resource-token IDs, whatever ends up observing a death.

➡️ Q1 stays open and stays a probe. It reruns against the runtime that succeeds the spike, and the useful thing this pass produced is the shape of the question — what hosts a queen, does that host have an identity, what signs the event — rather than an answer to it.

<!-- larandar:groom:v1 --> ## Correction to the probe above — 2026-09-04 **Freeholder correction: vordr is a spike. Its current shape is not the final state.** The observations in the previous comment stand as observations — `queen.Queen` is an in-process interface today, `os/exec` spawns only drones and the frontend, and there is no monitor identity or event schema in that tree. What does **not** stand is what I concluded from them. **The error.** I wrote that this record *"describes a boundary that does not exist"* and recommended recasting it as a design question or closing it as superseded. That converts *"the spike has not built this"* into *"the architecture does not have this"*, which the evidence does not support. A spike is a thing built to answer a founding question, not a statement about what the runtime will hold; absence in it is absence of a decision, not a decision against. **What the probe actually established**, restated honestly: - No monitor boundary exists **in the spike**. That is a fact about the spike. - The estate has therefore **not yet chosen** what hosts a queen, whether that host carries an identity, or what would sign a death event. Unchosen, not refused. - `warden.Sentinel`'s scope is genuinely drone-birth rather than queen-death, and the vordr#93 late-observer fix is genuinely drone-scoped. Those hold regardless of what the runtime becomes, and are the reusable part. **What this changes for the record.** Q1 asked for the deployed monitor boundary so this design could be specified against it. The correct answer is *not yet determined*, not *does not exist* — so this stays a Deliverable waiting on a prerequisite, exactly as it was, rather than becoming a proposal to be argued down. The recommendation in the previous comment is **withdrawn**. Q3's ratified ruling is untouched by any of this: the invalidation plane stops at OpenBao leases and exact resource-token IDs, whatever ends up observing a death. ➡️ Q1 stays open and stays a probe. It reruns against the runtime that succeeds the spike, and the useful thing this pass produced is the shape of the question — what hosts a queen, does that host have an identity, what signs the event — rather than an answer to it.
larandar commented 2026-09-03 23:03:05 +00:00
Owner
Copy link

Second correction — the probe examined an unestablished artifact, 2026-09-04

Freeholder: "I don't know that I ever ran a swarm from vordr successfully, where I ran a few with claude."

This goes further than the correction above it, and it invalidates the probe's premise rather than its conclusion.

Q1 asks for the actual Queen runtime and process boundary. I read swarm/vordr and reported its internals as the answer, without ever establishing that vordr is what runs swarms. It may never have run one successfully. The swarms that have actually run were Claude-driven.

So the probe answered "what shape does vordr have" when the question was "what runs a swarm". Everything in my first comment's result table is a description of an artifact whose relevance to this record is unestablished — including the parts I stated most confidently.

This is the second pass to make the same mistake. The 2026-08-26 grooming record on this issue opens "The checked Vordr runtime has an in-process Queen fleet, a drone-birth sentinel, and explicit operator restart" — reading vordr as the runtime, exactly as I did. Two passes have now treated a spike as the deployed system because it is the repository that looks like one.

What survives. Only the vordr-internal observations, and only as facts about vordr: the sentinel is drone-birth scoped and counts printable bytes rather than bytes; its late-observer fix re-checks under lock. Useful engineering, no bearing on this record.

What Q1 still needs, and now needs first: which runtime actually runs a swarm today? Until that is named, there is no tree to inspect for a process boundary, a death signal, or a monitor identity — and any answer produced by reading a repository nobody confirmed is running is a guess with citations.

➡️ Q1 stays open, with its first step corrected: name the runtime before probing one. Q3's ratified ruling is unaffected — it constrains what a death may invalidate, whatever turns out to observe one.

<!-- larandar:groom:v1 --> ## Second correction — the probe examined an unestablished artifact, 2026-09-04 **Freeholder:** *"I don't know that I ever ran a swarm from vordr successfully, where I ran a few with claude."* This goes further than the correction above it, and it invalidates the probe's premise rather than its conclusion. **Q1 asks for the *actual* Queen runtime and process boundary.** I read `swarm/vordr` and reported its internals as the answer, without ever establishing that vordr is what runs swarms. It may never have run one successfully. The swarms that have actually run were Claude-driven. So the probe answered *"what shape does vordr have"* when the question was *"what runs a swarm"*. Everything in my first comment's result table is a description of an artifact whose relevance to this record is unestablished — including the parts I stated most confidently. **This is the second pass to make the same mistake.** The 2026-08-26 grooming record on this issue opens *"The checked Vordr runtime has an in-process Queen fleet, a drone-birth sentinel, and explicit operator restart"* — reading vordr as **the** runtime, exactly as I did. Two passes have now treated a spike as the deployed system because it is the repository that looks like one. **What survives.** Only the vordr-internal observations, and only as facts about vordr: the sentinel is drone-birth scoped and counts printable bytes rather than bytes; its late-observer fix re-checks under lock. Useful engineering, no bearing on this record. **What Q1 still needs**, and now needs first: *which runtime actually runs a swarm today?* Until that is named, there is no tree to inspect for a process boundary, a death signal, or a monitor identity — and any answer produced by reading a repository nobody confirmed is running is a guess with citations. ➡️ Q1 stays open, with its first step corrected: **name the runtime before probing one.** Q3's ratified ruling is unaffected — it constrains what a death may invalidate, whatever turns out to observe one.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
fastlane
main
tango/2-bootstrap
No results found.
Labels
Clear labels
  
Compat/Breaking
Breaking change that won't be backward compatible

  
Kind/Bug
Something is not working

  
Kind/Documentation
Documentation changes

  
Kind/Enhancement
Improve existing functionality

  
Kind/Feature
New functionality

  
Kind/Security
This is security issue

  
Kind/Testing
Issue or pull request related to testing

  
Meta/Campaign
Campaign grouping node; dependencies name its direct Epics

  
Meta/Epic
Epic grouping node; dependencies name its direct Sessions

  
Meta/Session
Session delivery bundle; dependencies name its direct leaf issues

  
Priority/Critical
The priority is critical

  
Priority/High
The priority is high

  
Priority/Low
The priority is low

  
Priority/Medium
The priority is medium

  
Reviewed/Confirmed
Issue has been confirmed

  
Reviewed/Curated
PR LABEL: merge by rebase/ff to preserve the commit line; absence means squash. Set by the AUTHOR. (Curation itself is a duty on every PR — the label only picks the merge style.)

  
Reviewed/Duplicate
This issue or pull request already exists

  
Reviewed/Invalid
Invalid issue

  
Reviewed/Won't Fix
This issue won't be fixed

  
Scope/Campaign
Umbrella issue grouping a coherent multi-issue campaign.

  
Status/Abandoned
Somebody has started to work on this but abandoned work

  
Status/Blocked
Something is blocking this issue or pull request

  
Status/Conflicted
STATE: steward rebase failed; work returned to its agent, with evidence.

  
Status/In Progress
STATE: claimed, workspace active. Exactly one assignee, or none when idle.

  
Status/In Review
STATE: PR open against fastlane. Set by steward (PR webhook).

  
Status/Need Grooming
Issue body and comments do not yet conform to the Deliverable record; grooming required.

  
Status/Need More Info
Feedback is required to reproduce issue or to continue work

  
Status/Ready
Ready for execution; no known blocker prevents useful work from starting.

No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Meta/Campaign
Meta/Epic
Meta/Session
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
Reviewed/Confirmed
Reviewed/Curated
Reviewed/Duplicate
Reviewed/Invalid
Reviewed/Won't Fix
Scope/Campaign
Status/Abandoned
Status/Blocked
Status/Conflicted
Status/In Progress
Status/In Review
Status/Need Grooming
Status/Need More Info
Status/Ready
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Ting/Vedanta#13
No description provided.