replace ad hoc driver loading with a proper driver manager, new DDK, new PnP manager with device matching, asynchronous startup, resource ownership and removal, add shared PCI capability helpers, replace typed, rigid services with a proper service manager, implement proper system shutdown and restart, shutting down unloads drivers and shuts down services, add simple power button, remove heavyweight boot self-tests and SMP stress runs, add monotonic timestamps to kernel debug output, fruitless USB and PS/2 fixes, make test builds opt in.

docs.md

@@ -4,12 +4,12 @@ nt-lite is a clean-design hobby kernel. It is not a stable compatibility platfor
 
 ## Principles
 
-- Break old code when the new model is better.
+- Break old code.
 - Breaking ABI is encouraged.
-- Do not keep compatibility paths unless they have a clear purpose.
+- Do not keep compatibility paths.
 - Plan the model before writing the patch.
 - Make one architectural move at a time.
-- Delete stale paths once the real path works.
+- Delete stale paths, treat like wildfire.
 - Prefer compile failures over wrappers that hide stale users.
 - Keep the tree internally consistent.
 - Keep one canonical API for each operation.
@@ -21,18 +21,14 @@ nt-lite is a clean-design hobby kernel. It is not a stable compatibility platfor
 ## Workflow
 
 - Keep patches reviewable.
-- Boot-test meaningful changes.
 - Add diagnostics before optimizing.
 - Use logs, counters, and assertions instead of guessing.
 - Remove stale comments and dead code as part of the same cleanup.
 - Treat a fallback as either a supported mode or delete it before it becomes permanent.
-- Ask design questions before changing API shape, object lifetime, ownership, cancellation, persistence, or compatibility behavior.
+- **Ask design questions before changing API shape, object lifetime, ownership, cancellation, persistence, or compatibility behavior.**
 - Do not add a side path to avoid updating callers.
 - When changing an interface, update every caller in the same patch.
 - When adding a build artifact, update build, packaging, copy, and runtime discovery paths in the same patch.
-- Do not count apply checks or syntax-only checks as a real build.
-- Be precise about what was actually validated.
-- If behavior can be tested cheaply, include a focused runtime test or a visible diagnostic.
 - Prefer counters that prove both success and non-use.
 
 ## Breaking changes
@@ -54,7 +50,6 @@ Breaking changes are encouraged. When making one:
 - When asked to provide the full tree, also provide the patch.
 - The patch is for review; the full tree is for reproducing the exact baseline.
 - Avoid optimistic claims.
-- Do not introduce compatibility aliases unless they are intentionally supported API.
 
 ## Comment style
 
@@ -63,13 +58,14 @@ Breaking changes are encouraged. When making one:
 - Use sentence case.
 - End every sentence with a period.
 - Every owned source file should start with a short file comment.
-- Every function should have a comment, even if it is only a one-line summary.
 - Keep the tone practical and technical.
 - Humor is allowed rarely, but never instead of the real explanation.
-- Debugging history belongs in comments only when it explains a lasting constraint.
+- Debugging history belongs in comments is forbidden.
+- Describing past state in comments is forbidden.
+- Always describe what something is rather than isn't.
+- Avoid the word 'not'.
+- Keep comments short.
 - Document workarounds by saying what looks strange, why it is necessary, and what breaks if it is simplified.
-- Avoid trailing comments except for flags, bitfields, register tables, and packed layouts.
-- Keep real limitations as normal prose.
 
 ## Development lessons
 
@@ -91,12 +87,11 @@ Breaking changes are encouraged. When making one:
 - Prefer finishing the feature the user needs over endlessly polishing the audit around it.
 - Do not hide uncertainty. Say what was checked and what still needs a real build or boot test.
 
-## comments from developer
+## comments from angry developer to ai
 
 - 0x%016llX over %p, it looks prettier and is standard.
-- never add Ex, it makes me mad, never, rearchitect instead
 - i do put a focus on overengineering if it means it will be cleaner and futureproof
-- **ASK QUESTIONS!** i can't stress this enough. never assume you know the right answer. if you do, you are probably wrong.
+- **ASK QUESTIONS!** i can't stress this enough. never assume you know the right answer. if you do, you are probably wrong but you keep doing it.
 - **DISCUSS!** if it comes to designing something, anything, discuss it with me first. often times i can suggest something simpler, faster and elegant.
 - shift the syscall number table every time you add a syscall, do not append to the end
 - do not worry if a patch breaks something, it's better to break, document and fix rather than work around it.