chore(ci): update image paths

01_literature/DuckDB demo and showcase.md

@@ -44,8 +44,8 @@ DuckDB is a great starting point for modern stacks that don't need to worry abou
 ## Workshop Screenshots
 *This demo is from our pilot project, `note.d.foundation`, where we aggregate metadata from markdown notes imported from Notion into a parquet file to query data.*
 
-![](November Forward Engineering 2023-20231130164855761.webp)
+![](assets/November Forward Engineering 2023-20231130164855761.webp)
 
 *This demo is taken from Modal's example of using [DuckDB to analyze taxi NYC data in parallel over HTTPFS](https://modal.com/docs/examples/duckdb_nyc_taxi). It shows the power of DuckDB as a database engine and the flexibilities of having a local tool as opposed to a server-instantiated database.* 
 
-![](November Forward Engineering 2023-20231130165019170.webp)
+![](assets/November Forward Engineering 2023-20231130165019170.webp)

01_literature/Labs Roadmap (Nov 23 update).md

@@ -22,7 +22,7 @@ Our discussions have led to the identification of several intriguing topics, eac
 | **MPC**          | Huy Nguyen | - [[applying-mpc-for-authentication-for-web3-console\|Applying MPC for authentication for web3 (Console)]]                                                                                                                                                                                                                                                |
 | **UI practices** | Thanh Pham | - [[mochi-ui\|Build mochi-ui]]                                                                                                                                                                                                                                                                                                                            |
 
-![](labs-roadmap-(nov-23-update)-20231127143515779.webp)
+![](assets/labs-roadmap-(nov-23-update)-20231127143515779.webp)
 
 As we concentrate on these topics, other potential areas will stay in our backlog for the time being. However, these are open for exploration by members of the Labs and Dwarves teams, should they spark interest:
 

01_literature/why-micro-frontend.md

@@ -31,17 +31,17 @@ In a lot of cases, this approach is fine, it works if you do it right and a lot
 
 There might be a need for a more efficient solution - by breaking it down:
 
-![](playground/_memo/assets/why-micro-frontend/149cb7501d21ad52e476f168b93085cc_MD5.jpeg)
+![](assets/149cb7501d21ad52e476f168b93085cc_MD5.jpeg)
 ![](assets/why-micro-frontend_149cb7501d21ad52e476f168b93085cc_md5.webp)
 
 We can see that the backend work has been broken into microservices - a term we are probably too familiar with at this point. However, front-end work is still one big chunk. This is where micro-frontend comes in.
 
 ### The Micro-Frontend Architecture
 Let’s take the previous monolithic example (The Shop Team), broken into micro-frontends:
 
-![](playground/_memo/assets/why-micro-frontend/8b4ce5b2e752b7bbc96be21b6d2f1349_MD5.jpeg)
+![](assets/8b4ce5b2e752b7bbc96be21b6d2f1349_MD5.jpeg)
 ![](assets/why-micro-frontend_8b4ce5b2e752b7bbc96be21b6d2f1349_md5.webp)
-![](Pasted image 20231101050539.webp)
+![](assets/Pasted image 20231101050539.webp)
 With micro-frontends, codebase, teams, and responsibilities are split vertically in a way that the coupling between them is very low. Each team owns a smaller codebase, and can individually test, deploy and scale according to the needs. Now the teams only need to coordinate the moving parts, which can be kept minimal with a good system design. The teams can easily manage their dependencies and even use a separate tech stack.
 
 Finally, all micro-frontends can be served to the users altogether through a container (shell) app: