Closed and updated a number of items in ./issues

issues/bug:-create-in-collection-doesnt-render/description

@@ -1,21 +0,0 @@
-The "createInCollection" widget doesn't render keypresses on every press
-
---- @0.0.8
-For some reason, I'm not entirely sure why, the widget doesn't get every update when keys are pressed. I think it has something to do with the update function specific to the widget, as the bug seems localized to just this widget.
-
-The bug can be recreated by trying to enter any text (especially noticeable upon backspace) after pressing "c" in the collection view.
-
---- @0.0.8
-Upon some further investigation, it doesn't seem to be the update func? Is there some delay between the render and update cycle? It feels like its coming in a string -> content cycle too late?
-
-It might be worthwhile stepping back through history to find exactly *when* the bug was introduced. I think it might be related to the viewport specifically?
-
---- @0.0.8
-Upon further reflection, is the widget not somehow like... "embedded" in the collection browser?
-
---- @86eb3fe
-I'm not entirely sure what was wrong with the "createInCollection" widget, but I've reimplemented it as "setTitle". I *think* it might have had to do with dispatching a render cmd before the update cmd.
-
-Ultimately, this change is pretty much just a refactor and renaming of the existing "createInCollection" widget - so I see no reason not to push the changes.
-
-

issues/bug:-create-in-collection-doesnt-render/status

@@ -1 +0,0 @@
-patched

issues/bug:-tui:-footer-does-not-wrap/description

@@ -1,8 +0,0 @@
-Footer does not smart-wrap when it is too large for the screen
-
----@0.0.8
-golang `lipgloss` has bindings for wrapping text to a max size. Additionally, we may want to look at more intelligently handling keyhelps. Is it worth it to investigate the bubbles keyhelp widget?
-
----@4b60645
-Implemented some simple wrapping logic in the Model footer function. Further logic required in widget specific keyhelps to further wrap effectively.
-

issues/bug:-tui:-footer-does-not-wrap/status

@@ -1 +0,0 @@
-patched

issues/feat: implement "renaming"/description

@@ -1,10 +0,0 @@
-There isn't a good way to "rename" variadic's via the tui
-
----
-It wouldn't be too hard to add a method of varifying that the state of the variadic on disk mirrors the variadic in memory. For example, when writing a variadic, remove any existing fields that are not mirrored in memory.
-
-This would require some amount of confirmation from the user before we "delete" the previous state.
-
----
-This is not just for variadics, this spreads across the project - even to the entire Issue object. It *might* be worth it to implement separate logic for renaming Issues.
-

issues/feat: implement "renaming"/status

@@ -1 +0,0 @@
-open

issues/roadmap: CRUD life cycle/description

@@ -1,13 +0,0 @@
-CRUD access model completion
-
----
-
-All functions but delete fully implemented
-
---- arianagiroux(ariana.giroux@gmail.com)@2f2c511
-
-Should we even implement a top level delete function? They can be removed via `rm -r` by the user anyways. Definitely implement it in the TUI tho...
-
---- @0764e57
-A delete command has been added to the issue collection browser.
-

issues/roadmap: CRUD life cycle/status

@@ -1 +0,0 @@
-patched

issues/roadmap: project colours/description

@@ -1,4 +0,0 @@
-Define project wide colours
-
-Also, consider setting a monochrome flag during execution?
-

issues/roadmap: project colours/status

@@ -1 +0,0 @@
-open

issues/roadmap:-mature-styling/description

@@ -1,4 +0,0 @@
-Reach a final, consistent style across application.
-
-For example, decide between "fullscreen" or not, border styles,whether to use border styles or not, etc.
-

issues/roadmap:-mature-styling/status

@@ -1 +0,0 @@
-open