diff --git a/chapter_27_hot_lava.asciidoc b/chapter_27_hot_lava.asciidoc
index a30fa004..819ab1ce 100644
--- a/chapter_27_hot_lava.asciidoc
+++ b/chapter_27_hot_lava.asciidoc
@@ -11,7 +11,7 @@ and the end of our journey with this To-Do app and its tests.
 Let's recap our test structure so far:
 
 * We have a suite of "functional tests" that use Selenium to test that the whole app really works.
-  On several occations, the FTs have saved us from shipping broken code,
+  On several occasions, the FTs have saved us from shipping broken code,
   whether it was broken CSS, a broken database due to filesystem permissions, or broken email integration.
 
 * And we have a suit of "unit tests" that use Django's test client,
@@ -175,6 +175,9 @@ The problem is that these things don't scale linearly.
 The more database tables you have,
 the more relationships between them,
 and that starts to increase geometrically.
+// SEBASTIAN: That holds true as long as relationships number grows with database tables.
+//      I would add here or in the section about architecture that keeping project decoupled by having autonomous modules
+//      will replace geometrical penalty increase with linear one.
 
 So you can see why, over time, these kinds of tests
 are going to fail to meet our desiderata because they're too slow
@@ -313,6 +316,8 @@ Often people use it to mean the same thing as functional tests or end-to-end tes
 But as taught to me by one of the legends of QA at MADE (hi Marta!),
 _any_ kind of test can be an acceptance test,
 if it maps onto one of your acceptance criteria.
+// SEBASTIAN: Great point! I think of acceptance tests as part of second, parallel classification of tests.
+//      Unit tests, for example, are about scope of SUT. Acceptance tests are about purpose of testing.
 
 The point of an acceptance test is to validate a piece of behaviour
 that's important to the user.
@@ -347,6 +352,10 @@ the use of mocks comes with painful trade-offs.
 * And in the extreme, you can sometimes end up with mocks testing mocks,
   almost entirely disconnected from what the code actually does.
 
+// SEBASTIAN: Tight coupling to implementation details is debatable. That happens if one mocks whatever they feel like.
+//      If one mocks 'stable interfaces', e.g. Gateways or Service layer of another 'unit'/'module' then it's not coupling to implementation details
+//      Perhaps there is some middle-ground here, like Mocks lead us astray to mock whatever stands in our way and skipping this part of building solid abstractions?
+
 Ed Jung calls this https://youtu.be/CdKaZ7boiZ4[Mock Hell].
 
 This isn't to say that mocks are always bad!
@@ -407,7 +416,7 @@ because "Cosmos" is the opposite of "Chaos", in Greek.
 *******************************************************************************
 
 
-==== Ports and Adapters/Hexagonal/Onion/Clean Architecture
+==== Ports and Adapters/Hexagonal/Onion/the Clean Architecture
 
 The classic solutions to this problem from the OO world
 come under different names, but they're all variations on the same trick:
@@ -424,7 +433,9 @@ image::images/twp2_2601.png["Illustration of ports and adapaters architecture, w
 
 This pattern, or variations on it, are known as
 "Hexagonal Architecture" (by Alistair Cockburn),
-"Clean Architecture" (by Robert C. Martin, aka Uncle Bob),
+"the Clean Architecture" (by Robert C. Martin, aka Uncle Bob),
+// SEBASTIAN: it's "THE Clean Architecture", not just "Clean Architecture".
+//      https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
 or "Onion Architecture" (by Jeffrey Palermo).
 
 
@@ -486,8 +497,11 @@ that it can provide them most of the feedback they need about whether the system
 
 Not everywhere is Facebook!  But it's a good indication that automated tests
 aren't the be-all and end-all.
+// SEBASTIAN: This could use a mention of "shift-right" and perhaps a link or two in further reading to discover this fascinating world of testing in prod
 *******************************************************************************
 
+// SEBASTIAN: In this section, I very much miss any mention about internal project's modularity, such as can be achieved by using 'vertical slices'.
+//      Shameless plug: in my book, I devoted a whole chapter to it. From maintainability perspective, it's much more rewarding in the long term than horizontal slicing or decoupling from IO/external world as achieved with P&A/the Clean architecture etc.
 
 === The Hardest Part: Knowing When to Make the Switch