url fixes

Author: gallayl

src/content/posts/003-getting-started-with-inject.md

@@ -62,10 +62,10 @@ The package defines four types of lifecycle:
 
 ## ~~Extension methods~~
 
-[(We have already said goodbye to extension methods)](/008-byebye-extension-methods/)
+[(We have already said goodbye to extension methods)](/posts/008-byebye-extension-methods/)
 
 A simple injector can be easily extended by 3rd party packages with extension methods, just like the FuryStack packages. These extension methods usually provides a _shortcut_ of an instance or sets up a preconfigured explicit instance of a service. You can build clean and nice fluent API-s in that way - you can get the idea from one of the [FuryStack Injector Extensions](https://github.com/furystack/furystack/blob/develop/packages/rest-service/src/injector-extensions.ts)
 
-You find more inject-related articles [here](/tags/inject) or check out the package at NPM
+You find more inject-related articles [here](/tags/inject/) or check out the package at NPM
 
 [![npm](https://img.shields.io/npm/v/@furystack/inject.svg?maxAge=3600)](https://www.npmjs.com/package/@furystack/inject)

src/content/posts/007-data-validation-with-rest-and-json-schema.md

@@ -22,7 +22,7 @@ excerpt: We have a strongly typed REST API interface with build-time type checki
 
 ### Prerequisites
 
-Read the [previous article](/006-getting-started-with-rest) about type-safe REST APIs, if you haven't yet. It will give a huge boost on productivity. Seriously... go go go...
+Read the [previous article](/posts/006-getting-started-with-rest/) about type-safe REST APIs, if you haven't yet. It will give a huge boost on productivity. Seriously... go go go...
 So, glad you've back. Now let's get down to business...
 
 ### Some sad facts about Typescript interfaces - and a possible solution

src/content/posts/009-inject-refactor.md

@@ -11,7 +11,7 @@ excerpt: Emitting decorator type data is doomed :(
 
 ## Why
 
-As you can see, in FuryStack I've tried to take some steps to use only standardized APIs to maintain the supportability. As I started to work with new tools and framework, I've found some bottlenecks. The first big bad was the hacky [extension method support](/008-byebye-extension-methods/) that I've introduced in the beginning of the project, but I've found an another black sheep in the heart of the Typescript ecosystem - Decorator support.
+As you can see, in FuryStack I've tried to take some steps to use only standardized APIs to maintain the supportability. As I started to work with new tools and framework, I've found some bottlenecks. The first big bad was the hacky [extension method support](/posts/008-byebye-extension-methods/) that I've introduced in the beginning of the project, but I've found an another black sheep in the heart of the Typescript ecosystem - Decorator support.
 
 In short: "[The emitDecoratorMetadata flag is intentionally not supported.](https://github.com/evanw/esbuild/issues/257#issuecomment-658053616)"