+
+This is just supposed to be a simple terminal emulator application.
+It ought to be a rather simple exercise.
+
+
++++
+
+While I despise the Unix terminal, I can't just stop using Unix tools, and so
+I'll need a means to interact with them. One day it might evolve into
+a graphical terminal with a tty compatibility layer, which would need
+integrating a custom POSIX shell such as https://github.com/mvdan/sh[].
diff --git a/Identity.adoc b/Identity.adoc
new file mode 100644
index 0000000..b7eac66
--- /dev/null
+++ b/Identity.adoc
@@ -0,0 +1,33 @@
+Identity
+========
+
+The name "haven" merely hints at motivations and otherwise isn't of any
+practical significance other than that we need an identifier. (This time
+I resisted using something offensive for personal amusement.)
+
+A logo covering the entire project is not needed and it seems hard to figure out
+anything meaningful anyway, though we might pick a specific font to use for the
+project's name <1>.
+
+ __
+ <2> _/ /_ <1> | _ _ _ _
+ \ _ \ |/ \ / \| \ / /_\ |/ \
+ / / / / | | | | \ / | | |
+ /_/ /_/ | | \_/| \/ \_/ | |
+
+That being said, if any symbol is deeply desired, a simple "h" <2> or "hvn"
+could work. I'm not sure where I took this "h" letter styling from, it seems
+too familiar. The above illustrations also show how awful it looks when a logo
+is just a stylized version of the first letter of a name when you put the two
+next to each other. Distinctly redundant. Facebook and Twitter are doing fine,
+though, perhaps because they do not use them together like that.
+
+Mascots
+-------
+I can think of two kinds of mascots that would bring me joy: an anime-style
+character, or a My Little Pony OC. The color scheme would be mostly grayscale,
+with something like shades of orange thrown in.
+
+Either of the two choices is hard to draw for me if I don't want to infringe on
+someone else's copyright, so I might have to find someone else to do it.
+Eventually. Priorities lie elsewhere.
diff --git a/Technicalities.adoc b/Technicalities.adoc
new file mode 100644
index 0000000..9fde623
--- /dev/null
+++ b/Technicalities.adoc
@@ -0,0 +1,77 @@
+Technicalities
+==============
+
+Languages
+---------
+Primarily Golang with limited C interfacing glue, secondarily C++17, mostly for
+when the former cannot be reasonably used because of dependencies.
+
+Build system
+------------
+https://github.com/zevv/bucklespring is a good example of a rather simplified
+project that makes do with a single Makefile, even for cross-compilation on
+Windows. Let us avoid CMake and the likes of it.
+
+It seems that Go can link dynamically, therefore I could build libhaven.so
+(https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ
+and https://stackoverflow.com/questions/1757090/shared-library-in-go)
+and have the rest of the package as rather small binaries linking to it.
+The "cannot implicitly include runtime/cgo in a shared library" error is solved
+by "go install", which again requires "-pkgdir" because of privileges.
+libstd.so is a beautiful 30 megabytes (compared to libc.a: 4.9M).
+
+GUI
+---
+Probably build on top of X11/Xlib or xgb. Wayland can wait until it
+stabilizes--it should not be a major issue switching the backends.
+Vector graphics can be handled by draw2d.
+
+ - https://rosettacode.org/wiki/Window_creation/X11#Go
+ - https://github.com/llgcode/draw2d
+
+The c2 wiki unsurprisingly has a lot of material around the design and
+realisation of GUIs, which might be useful.
+
+It seems like an aligning/constraint-based "layout manager" will be one of the
+first harder problems here. However I certainly don't want to use fixed
+coordinates as they would introduce problems with different fonts and i18n.
+
+We could use BDF fonts from the X11 distribution, but draw2d has native support
+for FreeType fonts and it's more of a choice between vectors and bitmaps.
+
+The looks will be heavily inspired by Haiku and Windows 2000 and the user will
+have no say in this, for simplicity.
+
+.Resources:
+ - https://github.com/golang/exp/tree/master/shiny is a GUI library
+ - https://github.com/as/shiny is a fork of it
+ - http://man.cat-v.org/plan_9/1/rio has a particular, unusual model
+
+Internationalisation
+--------------------
+For i18n https://github.com/leonelquinteros/gotext could be used, however I'll
+probably give up on this issue as I'm fine enough with English.
+
+Go also has x/text packages for this purpose, which might be better than GNU,
+but they're essentially still in development.
+
+Versioning
+----------
+Versions are for end users. We can use a zero-based, strictly increasing
+number, be it a simple sequence or date-based numbers such as 1807. If we do
+this at all, we will eventually also need to release patch versions.
+
+Since dates don't seem to convey important information, let us settle on 0, 1,
+1.1, 2, 3, 3.1, 3.2, ... In practice releases are going to be scarce, unless
+we find a person to take care of it. Note that there is no major/minor pair--
+a new project will be created when radical philosophical or architectural
+changes are to be made. See Goal.
+
+Licensing
+---------
+All will be released into the public domain. The preferred way of doing so is
+the 0BSD license.
+
+Other people's libraries may be used or even imported if it makes sense, so long
+as they're not licensed under something either viral like the GPL, or annoying
+such as the original 4-clause BSD license.
diff --git a/header.tmpl b/header.tmpl
new file mode 100644
index 0000000..92a9fed
--- /dev/null
+++ b/header.tmpl
@@ -0,0 +1,24 @@
+