chore: convert TODO to MIME TODO format and add issues 5-9

TODO

@@ -1,51 +1,5 @@
-# TODO List for esm-logging
+--ISSUE
-
+Content-Type: application/issue
-This is a poor-man's issue tracker. I am not primarily a GitHub user so don't
-want to commit to their issue tracking feature, but my primary SVC service
-provider (Bitbucket) only offers paid integration into their issue tracker
-(Jira). I don't have the time (and patience) at the moment to analyze the best
-approach, so this file will have to suffice.
-
-It's a very simple concept: Track any issues (features, bugfixes, hotfixes) in
-here, assign a sequential number to it and use that number when branching.
-
-I will try to develop a format so that I can parse the file later on, should I
-decide to migrate to a real issue tracker. It's probably going to be Bugzilla,
-but for that my html-theme-ref project needs to stabilize first.
-
-## Format Specification
-
-The file uses Markdown conventions for formatting headers and other text block
-entitities, but SHOULD NOT be considered a Markdown file. That's why it has no
-definitive file extension.
-
-Each issue entry follows a structured format for easier parsing and future
-migration.  Issues MUST be **appended** to this file and never moved, to
-preserve Git diffing.
-
-### Issue Format
-
-```
-
-ID: [ISSUE-NUMBER]
-Type: [feature/bugfix/hotfix]
-Title: [Short title]
-Status: [open/in-progress/done]
-Priority: [low/medium/high]
-Created: [YYYY-MM-DD]
-Description: [Detailed explanation]
-
----
-```
-
-- ISSUE-NUMBERs must be sequential
-- truncation of description must be indentended so that every line starts at the
-  same column
-- issues must be started with two LF
-- issues must be terminated with two LF, then `---`
-- issues may have a free-text field (epilog), which must be started with two LF.
-
-## Issues
 
 ID: 1
 Type: feature
@@ -53,12 +7,14 @@ Title: string formatting utilities
 Status: in-progress
 Priority: high
 Created: 2025-05-01
+Relationships:
 Description: implement utilities for formatting strings. The formatting should
              be inspired by Python 3K PEP 3101 in addition to their standard
              library utilities starting from ver. 3.7. Optimizations should
              focus on V8 support.
 
----
+--ISSUE
+Content-Type: application/issue
 
 ID: 2
 Type: feature
@@ -66,13 +22,15 @@ Title: describe development workflow in CONTRIBUTING.md
 Status: open
 Priority: medium
 Created: 2025-05-01
+Relationships:
 Description: It's a good idea to describe the development workflow, including
              branching strategies earlier on, so that if someone is interested
              in forking, they can pick up right away. It's not meant for
              contributions though. I'm currently not interested in external
              contributions.
 
----
+--ISSUE
+Content-Type: application/issue
 
 ID: 3
 Type: bugfix
@@ -80,12 +38,14 @@ Title: modularize testing further
 Status: done
 Priority: high
 Created: 2025-05-01
+Relationships:
 Description: Since I am going to implement unit tests as well as integration
              tests and probably some benchmarks, it makes sense to introduce
              another sub-level directory for each type of test, say
-             `tests/unit/`, `tests/integration`, etc.
+             tests/unit/, tests/integration, etc.
 
----
+--ISSUE
+Content-Type: application/issue
 
 ID: 4
 Type: feature
@@ -93,6 +53,7 @@ Title: migrate testing framework from Jest to Mocha
 Status: in-progress
 Priority: high
 Created: 2025-05-01
+Relationships:
 Description: I really don't like behavior-driven testing, at least when it comes
              to unit testing. It feels like Walldorf education... Where I need
              to come up with an abstraction for describing my test. A function
@@ -101,4 +62,90 @@ Description: I really don't like behavior-driven testing, at least when it comes
              Hopefully Mocha is the savior. I'm sticking to xUnit based testing
              from now on.
 
----
+--ISSUE
+Content-Type: application/issue
+
+ID: 5
+Type: bugfix
+Title: fix critical bugs across core modules
+Status: open
+Priority: high
+Created: 2026-03-13
+Relationships:
+Description: multiple logic bugs prevent the library from functioning.
+             manager.ts getLogger() has an inverted type check and missing
+             return statement. config.ts basicConfig() assigns wrong option
+             fields (filemode instead of datefmt/style) and has unreachable
+             conditions. logger.ts isEnabledFor() always caches false,
+             _log() never calls handle(), and makeRecord() uses .keys()
+             instead of Object.keys(). handler.ts format() has no return
+             statement and is missing a formatter getter.
+
+--ISSUE
+Content-Type: application/issue
+
+ID: 6
+Type: feature
+Title: implement remaining Logger level methods
+Status: open
+Priority: high
+Created: 2026-03-13
+Relationships: dependsOn:5
+Description: Logger only implements debug(). The info(), warning(), error(),
+             and critical() methods are missing entirely. The _log() method
+             also needs to be completed so it actually calls handle() after
+             creating the LogRecord.
+
+--ISSUE
+Content-Type: application/issue
+
+ID: 7
+Type: feature
+Title: implement Formatter subsystem
+Status: open
+Priority: high
+Created: 2026-03-13
+Relationships: dependsOn:1
+Description: the three core Formatter methods are stubs returning placeholder
+             strings. PercentFormatterStyle._format() needs to perform actual
+             %-style field substitution against LogRecord attributes.
+             Formatter.formatTime() needs a JS Date/Intl-based implementation
+             replacing the Python time.strftime references.
+             Formatter.formatError() needs to format Error.stack into a
+             string. The datetime helper module is empty and needs time
+             formatting utilities.
+
+--ISSUE
+Content-Type: application/issue
+
+ID: 8
+Type: feature
+Title: implement browser-compatible Handler output
+Status: open
+Priority: high
+Created: 2026-03-13
+Relationships: dependsOn:5
+Description: StreamHandler has no emit() implementation and its constructor
+             ignores the stream parameter. The helper/stream module is a
+             stub that needs a browser-compatible Writable interface backed
+             by console output. FileHandler should be dropped or gated behind
+             a Node.js environment check since browser environments have no
+             filesystem write access. A ConsoleHandler targeting the browser
+             console API (console.log/warn/error by level) is the primary
+             output target.
+
+--ISSUE
+Content-Type: application/issue
+
+ID: 9
+Type: feature
+Title: implement Manager logger hierarchy
+Status: open
+Priority: high
+Created: 2026-03-13
+Relationships: dependsOn:5
+Description: Manager.getLogger() does not establish parent-child
+             relationships between loggers based on dot-separated names.
+             The Placeholder fixup logic is incomplete. Logger propagation
+             depends on this hierarchy being correctly built so that child
+             loggers forward records to parent handlers.