Update rendered RFCs (#303)

Co-authored-by: pipo02mix <[email protected]>

Author: github-actions[bot]

content/docs/rfcs/merging-configmaps-gitops/_index.md

@@ -83,7 +83,7 @@ spec:
 or should be left empty to be later populated by either `app-admission-controller`, upon submission, or `app-operator`, upon
 reconciliation. Using this field to provide other values may result in the mis-configuration of certain apps.**
 
-The values coming from these fields are merged based on their priority, see the [App Platform configuration](https://docs.giantswarm.io/tutorials/fleet-management/app-platform/app-configuration/). Both, the `.spec.config` and `.spec.userConfig`,
+The values coming from these fields are merged based on their priority, see the [App Platform configuration](https://docs.giantswarm.io/developer-platform/app-platform/app-configuration/). Both, the `.spec.config` and `.spec.userConfig`,
 fields get the fixed priorities, making their place in the hierarchy fixed as well, while the `.spec.extraConfigs` memebers
 priorities are configurable.
 

content/docs/rfcs/multi-layer-app-config/_index.md

@@ -12,7 +12,7 @@ toc_hide: true
 ## Intro
 
 Our current app delivery mechanism is by using App CRs. Currently, App CRs allow for
-[two layers](https://docs.giantswarm.io/tutorials/fleet-management/app-platform/app-configuration/). So far it was good enough to have these 2
+[two layers](https://docs.giantswarm.io/app-platform/app-configuration/). So far it was good enough to have these 2
 layers, but with our introduction of GitOps with Flux, this is starting to be a limiting factor.
 
 Basically, the problem starts when we have more than 2 layers (a base and an override) of configuration in a GitOps