diff --git a/pervognsen/bitwise/bitwise/bitwise007.hmml b/pervognsen/bitwise/bitwise/bitwise007.hmml
new file mode 100644
index 0000000..50833d3
--- /dev/null
+++ b/pervognsen/bitwise/bitwise/bitwise007.hmml
@@ -0,0 +1,67 @@
+[video member=pervognsen stream_platform=twitch project=bitwise title="More Order-Independent Declarations" vod_platform=youtube id=4AOnbPDyQXw annotator=Miblo]
+[0:08][Recap and set the stage for the day, with a plug of the GitHub commits newly tagged by day and the annotated episode guide][:speech]
+[3:45][Review off-stream work on buf__printf(), the Typespec struct and AST_DUP()][:memory :research]
+[8:08][Review the current status of order-independent declaration support, with the determination to redo it handling ordering first][:parsing :research]
+[13:41][Introduce order_decl() and order_typespec()][:parsing]
+[23:52][Introduce order_expr() and order_name()][:parsing]
+[31:54][Introduce order_test()][:parsing]
+[33:56][:Run it and hit a syntax error][:parsing]
+[34:22][Pull out code_decls\[i\] into a variable in order_test()][:parsing]
+[35:07][Step in to order_test() and realise that it calls parse_decl() incorrectly][:parsing :run]
+[35:29][Make order_test() call init_stream()][:parsing]
+[35:44][:Run it to see how it works][:parsing]
+[35:55][Make every function that doesn't need an argument take void as an argument][:language]
+[37:44][Introduce order_decls()][:parsing]
+[40:27][Step into order_decls() to see what's going on][:parsing :run]
+[40:41][Make order_decls() call order_name()][:parsing]
+[41:04][Step through order_decls()][:parsing :run]
+[41:34][Prevent main_test() from calling resolve_test()][:parsing]
+[42:15][Step back through order_test()][:parsing :run]
+[42:18][Add a variable-based declaration test case in order_test()][:parsing]
+[42:29][Step in to order_decl() and inspect the decl][:parsing :run]
+[43:18][Add an out-of-order test case in order_test()][:parsing]
+[43:25][Step recursively through order_decl() to see what it does][:parsing :run]
+[44:42][Add a cyclical declaration test case in order_test()][:parsing]
+[44:52][Step through order_decl() to see how it handles it][:parsing :run]
+[45:18][Add struct test cases in order_test()][:parsing]
+[46:29][Step in to order_decl() to see how it parses our structs][:parsing :run]
+[47:02][Introduce sym_builtin() to handle things like "int" in structs][:parsing]
+[49:16][:Run it to see how it handles our structs][:parsing :run]
+[50:20][Add an out-of-order declared struct member test case][:parsing]
+[50:47][:Run it to see how that works][:parsing :run]
+[51:09][Review the core of our algorithm, with the determination to handle pointers][:parsing :research]
+[56:33][Plan not to detect cycles in the ordering pass][:parsing :speech]
+[58:58][Q&A][:speech]
+[59:04][@nothings2][@pervognsen What case prevents you from just NOT ordering into pointer decls? If you said I missed it][:parsing]
+[59:27][@orcnz29][@pervognsen For order-independent declarations, could you first do a scan through the top level (order-independent) declarations (funcs etc.) registering the names in the symbol table as unresolved, then do a full pass and do the your recursive type resolution as you go? The extra initial scan would only be at the global / top scope so it would / should be quick][:parsing]
+[1:00:31][@xanatos387][Is all of this only needed for the C backend, or does it apply for our own codegen as well?][:language :parsing]
+[1:02:28][Consider the cases preventing us from not ordering into pointer declarations][:parsing :speech]
+[1:04:44][@nothings2][I think you have to do it that way, otherwise there's no way to get 'struct S { T t; }; struct T { S *s;};' to work][:parsing]
+[1:05:51][Validate [@nothings2 Sean]'s cases][:parsing :programming :run]
+[1:06:46][Consider implementing enum :parsing][:parsing :speech]
+[1:08:52][@nothings2][@pervognsen So you're not going to allow 'enum { A,B=X,C }; enum { X,Y=C,Z };'? I think it's possible to resolve it, but it's fine if you don't want to][:parsing]
+[1:11:19][Implement enum support, introducing a SymKind enum for all of our sym_*() functions, including a new sym_enum_const(), to use][:parsing]
+[1:19:12][Step in to order_decl() to see how enums get handled][:parsing :run]
+[1:21:00][Enable order_name() to handle SYM_DECL specially][:parsing]
+[1:22:08][:Run it to see that it works][:parsing]
+[1:22:10][Add some dependency tests in order_test()][:parsing]
+[1:22:30][:Run it to see what happens][:parsing]
+[1:24:14][Make order_name() call itself rather than order_decl()][:parsing]
+[1:24:43][:Run it and unexpectedly hit a cyclic dependency][:parsing]
+[1:25:23][Revert order_name() to call order_decl() for SYM_DECL, and itself only for SYM_ENUM_CONST][:parsing]
+[1:26:01][:Run it to see that it actually works[:parsing]]
+[1:26:19][Add an out-of-order declared enum test case in order_test()][:parsing]
+[1:26:29][:Run it to see that it works as expected][:parsing]
+[1:26:38][Mention that the enum stuff will change][:parsing :speech]
+[1:27:09][Q&A][:speech]
+[1:27:22][@nothings2][@pervognsen Can you put sym_decl() and the preceding function on the screen while you're talking? I was AFK while you did it]
+[1:27:58][@twicetimes][@pervognsen Will Ion have variable name shadowing?][:language]
+[1:29:17][@nothings2][I'd prefer to call that 'newcap' or something]
+[1:29:25][Rename the shadowed cap and n to new_cap and new_n in buf__printf()][:memory]
+[1:30:26][@nothings2][@pervognsen If you keep that code you have to assign n back to new_n, or replicate the final lines]
+[1:30:29][Revert buf__printf() to use the existing n, only renaming cap to new_cap][:memory]
+[1:31:08][A few thoughts on variable shadowing, and taking a step back and approaching problems from other directions][:speech]
+[1:36:34][@nothings2][@pervognsen Do you think your programming has changed since you were at RAD?]
+[1:38:07][@ezysigh][So, what kinds of things, i.e. what bad habits?]
+[1:39:55][That's enough philosophical digressions for one day][:speech]
+[/video]