diff --git a/LOG.md b/LOG.md
index 5d2003006c3294c7422772ad8950e2a03f8834f9..3445d72935aedec7db5b45b363cd943f999e287f 100644
--- a/LOG.md
+++ b/LOG.md
@@ -1,25 +1,55 @@
 # Cuttlefish Dev Log / Scratch Notes
 
-## Current Desires
+## Dev Golf
 
-- for dom API: follow the load-in path. what can you do (min viable) to make the hunk API make sense? write the load path down.
-- the resize issue (yikes! avoid!)
-- some example program ... do array ops on line history, plot like snake? arrow keys input? use delay to flow-control triggers for line-keeping ? kinda fun 
-- type clarity ??
+hour- + long tasks under existing structures,
 
-- good hunk documentation, (how to dev)
-- list of desired hunks (?)
-- .gitignore most saved systems / contexts etc
+```
+- assign meaning to charts and graphs (date / location / etc)  
+ - this should be generic json-object making, yeah? / csv
+- save tests as .json objects (optionally) develop program for reading  
+ - overlay multiples, save images  
+ - read-in csv as well, polymorphic for outputs
+- generic wrap / unwrap data objects ...
+- the force loop / layout (floop.js)
+ - wire length != zero
+ - better keepout-rectangles
+ - spawn new hunks at the mouse (floaters! things 'inside' of others!)
+ - how to do this all elegantly ... it's ah big redesign: take some hours, consider, maybe it's not so grand ?
+- sys / save etc
+ - dates & times in metadata on list ...
+ - save systems w/ layout ??
+- menu
+ - arrow keys to bump through items
+```
+
+## Aspirational Dev
+
+Things we want to see, extensions, etc,
+
+### Compound Types
+
+I was thinking about the cf 'api' / workings today. At the moment there is this convoluted / poorly named system where `the view messages the manager` with some similarely-but-not-well-named names. In the browser, these are actually hooked up through a messaging loop, to abstract in the same way in JS / CPP (remote) and / JS (remote). This was great for development, but there's another way to do it that might be much nicer for the future... which iiiis to retain the 'view' object, but (at the top level) attach each of it's core function (the eight) directly to the manager's reciprocal function, both cast as promises. Other views can call the same promises, but in those cases they're hooked to the view's messaging 'subsystem' ... put this note in the relevant repo.
+
+For mixed up data types / polymorphism / I just had this idea this morning (more of a clarification) about compound types, and their wraps. Compounds, and Compound Arrays. This is maybe worth some time, and some drawing. I was considering the Squid/Protocol in the context of big serverside apis / the microservices trend. This future where people don't build eachother's software source, but people plug into eachother's operating hardware: where we collaboratively wire together one big operative graph. To mux big data objects, we can wire up / bundle compound data types, named. This is a serialization that rests on our core set of byte-structures, and a wrapping / unwrapping tool, that names things. For instance: a compound wrapper is a hunk having some set of inputs, and one output. The inputs are typed / named as is tradition. Some of these can even be other compound data types. The wrapper (sync / async) takes data off of its inputs, and wraps them into one serialized message, that has some known 'compound' structure... Like, a list of names, then data bits all serialized in key, with type-keys leading. In the compound array messages, we have an array of these compound types (this is the CSV type), where we have one list of names, arrays of these type-keyed objects.
+
+This is a really nice thing that I would really want to see. Compounds should maybe have names, but should maybe just be id'd by their final roots: any ordered set of the-same types of data should be compatible with the same: that's really the data-type identifier... Noice.
+
+... treating data like this allows complex, application / architecture specific representations to be used, but bundles interoperability into the core datatypes we ... likely all agree on. this is on the expectation that computing becomes more specialized as we progress, not less.
+
+### Better Error Paths
+
+I do, really, want to use this as a wrench. The first component to that is to reconsider error- and logging paths. Though this might add some small delay, I can wrap the cuttlefish manager's loop in a try/catch loop (over per-hunk loops as well). I can write logs out to a floater that is associated with that def's core. Top level logs can come from the manager... bootstrap can catch very top level, those would be halting. Error paths should also default to logging to the console as well... and modifying both to change logging behaviour should be possible.
 
-- extra spice: arrow keys in the menu
+# Past Logging (Completed or Forgotten Tasks)
 
-## Next Desires
+## Next Desires (2019-09)
 
 I think that mostly I would like to focus on the potential of a KOA / Express cuttlefish & vfp package, to run local systems away from my active development.
 
 Following this, probably the best things to do will be address things like type inconsistencies, and add better error pathing... Also, tickets like the network-level view, and starting to daydream about the interstitial routing layer, if it exists? That awkward link.
 
-## The Latest
+## The Latest (2019-07)
 
 I'm excited about this, so here's two images:
 
diff --git a/README.md b/README.md
index 11e894b79e117039ee5e991400f6131ed1d000f2..c0b56503d1f0f4e6668b2a7f0b17984e1e4ac427 100644
--- a/README.md
+++ b/README.md
@@ -202,14 +202,3 @@ You can now run Cuttlefish by doing:
 ``node cf``
 
 It should then report an IP and port. One is your local address, if the browser you are using is on the same machine as the node process, and the other is the machine's outward facing IP. You should be able to point the browser to one of these IPs, and you're off and cuttling.
-
-# Dev Golf
-
-```
-- assign meaning to charts and graphs (date / location / etc)  
- - this should be generic json-object making, yeah? / csv
-- save tests as .json objects (optionally) develop program for reading  
- - overlay multiples, save images  
- - read-in csv as well, polymorphic for outputs
-- generic wrap / unwrap data objects ... 
-```
diff --git a/filesys.js b/filesys.js
index c4f9dfd7878659fd548b1d6d135868f341deaced..dd0f42f2d88350c0c591faa6068f50f6f50a784b 100644
--- a/filesys.js
+++ b/filesys.js
@@ -6,7 +6,6 @@ module.exports = {
   // get a tree: takes the root (relative the process) and returns all branches below,
   // includes route-to-root in list
   getDirTree: (dir, debug) => {
-    debug = true
     let tld = dir
     return new Promise((resolve, reject) => {
       // items and count,
@@ -46,7 +45,7 @@ module.exports = {
           if (!count) {
             // we sort,
             list.sort()
-            console.log('list at fin getDirTree', list)
+            if(debug) console.log('list at fin getDirTree', list)
             resolve(list)
           }
         }) // end fs.readdir
diff --git a/save/systems/vfpt-l1.json b/save/systems/vfpt-l1.json
new file mode 100644
index 0000000000000000000000000000000000000000..6fa5362947ae610b201a18434f2680a77a94a4e8
--- /dev/null
+++ b/save/systems/vfpt-l1.json
@@ -0,0 +1,179 @@
+{
+  "interpreterName": "cuttlefish",
+  "interpreterVersion": "v0.1",
+  "hunks": [
+    {
+      "type": "manager",
+      "name": "nrol",
+      "inputs": [
+        {
+          "name": "msgs",
+          "type": "byteArray"
+        }
+      ],
+      "outputs": [
+        {
+          "name": "msgs",
+          "type": "byteArray",
+          "connections": [
+            {
+              "inHunkIndex": "1",
+              "inHunkInput": "0"
+            }
+          ]
+        }
+      ]
+    },
+    {
+      "type": "view",
+      "name": "tlview",
+      "inputs": [
+        {
+          "name": "msgs",
+          "type": "byteArray"
+        }
+      ],
+      "outputs": [
+        {
+          "name": "msgs",
+          "type": "byteArray",
+          "connections": [
+            {
+              "inHunkIndex": "0",
+              "inHunkInput": "0"
+            }
+          ]
+        }
+      ]
+    },
+    {
+      "type": "link",
+      "name": "link_2",
+      "inputs": [
+        {
+          "name": "data",
+          "type": "byteArray"
+        },
+        {
+          "name": "mgrMsgs",
+          "type": "byteArray"
+        }
+      ],
+      "outputs": [
+        {
+          "name": "data",
+          "type": "byteArray",
+          "connections": [
+            {
+              "inHunkIndex": "3",
+              "inHunkInput": "0"
+            }
+          ]
+        },
+        {
+          "name": "mgrMsgs",
+          "type": "byteArray",
+          "connections": [
+            {
+              "inHunkIndex": "4",
+              "inHunkInput": "0"
+            }
+          ]
+        }
+      ],
+      "states": [
+        {
+          "name": "isActive",
+          "type": "boolean",
+          "value": "false"
+        },
+        {
+          "name": "otherLink",
+          "type": "uint16",
+          "value": "0"
+        },
+        {
+          "name": "inputList",
+          "type": "string",
+          "value": "mgrMsgs (byteArray)"
+        },
+        {
+          "name": "outputList",
+          "type": "string",
+          "value": "mgrMsgs (byteArray)"
+        }
+      ]
+    },
+    {
+      "type": "pipes/vfptc",
+      "name": "pipes/vfptc_3",
+      "inputs": [
+        {
+          "name": "data",
+          "type": "byteArray"
+        }
+      ],
+      "outputs": [
+        {
+          "name": "data",
+          "type": "byteArray",
+          "connections": [
+            {
+              "inHunkIndex": "2",
+              "inHunkInput": "0"
+            }
+          ]
+        }
+      ],
+      "states": [
+        {
+          "name": "pipe status",
+          "type": "string",
+          "value": "open"
+        },
+        {
+          "name": "websocket port",
+          "type": "string",
+          "value": "2042"
+        },
+        {
+          "name": "usb product id",
+          "type": "string",
+          "value": "8022"
+        },
+        {
+          "name": "pipe reset",
+          "type": "boolean",
+          "value": "false"
+        },
+        {
+          "name": "serialport status",
+          "type": "string",
+          "value": "open"
+        }
+      ]
+    },
+    {
+      "type": "view",
+      "name": "view_4",
+      "inputs": [
+        {
+          "name": "msgs",
+          "type": "byteArray"
+        }
+      ],
+      "outputs": [
+        {
+          "name": "msgs",
+          "type": "byteArray",
+          "connections": [
+            {
+              "inHunkIndex": "2",
+              "inHunkInput": "1"
+            }
+          ]
+        }
+      ]
+    }
+  ]
+}
\ No newline at end of file
diff --git a/view/vtoplevel.js b/view/vtoplevel.js
index bc7a51cf6eff3f657ae3f66d8cab3c27810941b1..c1b3e5be6510447412988da88d9664371fbf5a97 100644
--- a/view/vtoplevel.js
+++ b/view/vtoplevel.js
@@ -176,7 +176,7 @@ function makeTopLevel(view) {
     }
   })
 
-  let mousep = {}
+  let mousep = null
 
   document.addEventListener('mousemove', (evt) => {
     mousep = evt
@@ -191,8 +191,20 @@ function makeTopLevel(view) {
       // for this, we wrote a global mouse capture event ...
       evt.preventDefault()
       evt.stopPropagation()
+      console.log('kd', evt)
       if(mousep){
         cfContextMenu(mousep, view, dt)
+      } else {
+        console.log(view)
+        // probably a bugfarm, http://shrugguy.com
+        let falseEvt = {
+          target: view.dom,
+          clientX: view.dom.clientWidth/3,
+          clientY: view.dom.clientHeight/3,
+          preventDefault: function(){},
+          stopPropagation: function(){}
+        }
+        cfContextMenu(falseEvt, view, dt)
       }
     } else if (evt.key === 'k' && evt.ctrlKey) {
       evt.preventDefault()