From 7c55fa4dc95767efb1cb4c2b69872df5903ee8ab Mon Sep 17 00:00:00 2001
From: Sebastian Kuzminsky <seb@highlab.com>
Date: Sat, 12 Jul 2025 15:17:27 -0600
Subject: [PATCH] add comment bd8d26478108fde4e1a9f32507957e5f on issue
 08f0d7ee7842c439382816d21ec1dea2

---
 .../description                                 | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 08f0d7ee7842c439382816d21ec1dea2/comments/bd8d26478108fde4e1a9f32507957e5f/description

diff --git a/08f0d7ee7842c439382816d21ec1dea2/comments/bd8d26478108fde4e1a9f32507957e5f/description b/08f0d7ee7842c439382816d21ec1dea2/comments/bd8d26478108fde4e1a9f32507957e5f/description
new file mode 100644
index 0000000..a1b03ce
--- /dev/null
+++ b/08f0d7ee7842c439382816d21ec1dea2/comments/bd8d26478108fde4e1a9f32507957e5f/description
@@ -0,0 +1,17 @@
+I'm liking the idea of a per-issue key/value store.
+
+I think keys and values are both strings, with possible further
+parsing/interpretation for some keys?
+
+For the application in this issue we'd teach ent to create a "finished"
+key, maybe when setting the state to Done, with a value of an
+ISO8601-style datetime stamp (e.g. "2025-07-12T15:08:58-06:00").
+
+There would be a documented spec of reserved keys and their special
+meanings and handling.
+
+Full user access via CLI, maybe something like `ent get VARIABLE` and
+`ent set VARIABLE VALUE`?  Or `ent variable [NAME[=VALUE]]`?
+
+Or maybe merge this with the tags somehow?  Would that be simpler,
+or more complicated (for the user)?