doc: fix jargon and clean up stale doc

README.md

@@ -1,9 +1,6 @@
-### ** Coming soon: a new way to write the controller **
-
-We are developing a faster, more Kubernetes native and more reliable Config Connector reconciliation approach(Direct Controller).
-Thus, we decide to hold off any PRs about adding new TF-based or DCL-based resources until mid Q4 2024. 
-We will share more guidance about resource coverage in Q4 2024. Please stay tuned!
+### The direct Config Connector guide is ready
 
+We launched a major improvement to develope the Config Connector resources. This approach significantly enhances the reliability of the Config Connector object reconciliation and provides a more Kubernetes-native developing experience. Learn more in [the Direct resource development guide](./docs/develop-resources/).
 
 # GCP Config Connector
 

docs/develop-resources/README.md

@@ -1,8 +1,8 @@
-# Guide for Developing KCC Resources 
+# Guide for Developing Config Connector Direct Resources 
 
-We are thrilled to introduce the guide for adding Config Connector resources and fields! Resources built using this guide are called "KCC Direct Controllers", because they are built directly against the service API. Developing a new resource (or a new field) is much faster and more manageable using this new Direct Controller approach than previous approaches. We have changed some key resource reconciliation processes to be more reliable and Kubernetes-native. We have also made a revolutionary change to the test driven development and PR review process to improve test coverage for every field in a resource. 
+We are thrilled to introduce the guide for adding Config Connector resources and fields! Resources built using this guide are called "Config Connector Direct Controllers", because they are built directly against the service API. Developing a new resource (or a new field) is much faster and more manageable using this new Direct Controller approach than previous approaches. We have changed some key resource reconciliation processes to be more reliable and Kubernetes-native. We have also made a revolutionary change to the test driven development and PR review process to improve test coverage for every field in a resource. 
 
-While there is more work to be done to further improve the process of adding KCC resources, we believe the guide is now ready to be shared broadly, such that Google developers, partners, and customers can add KCC resources. We will continue improving this guide to make it simpler and easier to develop new KCC resources. Please stay tuned for the upcoming changes.
+While there is more work to be done to further improve the process of adding Config Connector resources, we believe the guide is now ready to be shared broadly, such that Google developers, partners, and customers can add Config Connector resources. We will continue improving this guide to make it simpler and easier to develop new Config Connector resources. Please stay tuned for the upcoming changes.
 
 # Contents
 

mockgcp/README.md

@@ -1,8 +1,8 @@
 # MockGCP 
 
-MockGCP contains stub implementations of GCP APIs, for use with testing KCC.  The implementations
+MockGCP contains stub implementations of GCP APIs, for use with testing Config Connector. The implementations
 don't do anything (there is no "backend") - creating a mock VM does not launch a VM.  Instead, the
-goal is to provide just-enough consistent CRUD operations to test the KCC providers.
+goal is to provide just-enough consistent CRUD operations to test the Config Connector providers.
 If the tests pass, we consider that to be a "good enough" mock for GCP.  When
 we discover an issue that the mocks failed to catch, we should update mockgcp
 to more accurately simulate GCP, ideally triggering the bug and then showing
@@ -84,7 +84,7 @@ If you are lucky, everything will "just work" and you will see that your new tes
 If something is not behaving as you would expect, you should be able to launch a debugger because it all runs in one process.
 You can also use `ARTIFACTS=artifacts` to get detailed HTTP logs of the traffic, which is useful if you want to see the json requests & responses.
 If you also use `E2E_GCP_TARGET=real` you can run against the real (non-mocked) GCP, and easily see what the actual behaviour should be.
-Usually however, this is not necessary; the most common failure mode is that terraform or KCC expects a field to be automatically populated,
+Usually however, this is not necessary; the most common failure mode is that terraform or Config Connector expects a field to be automatically populated,
 and it normally logs an error like "foo not set" (in this case, simply add that to your mock implementation.)
 
 ## Capture golden object and HTTP golden logs