diff --git a/app/src/display/widgets/layer_status.c b/app/src/display/widgets/layer_status.c
index 73c2268e..19e25d93 100644
--- a/app/src/display/widgets/layer_status.c
+++ b/app/src/display/widgets/layer_status.c
@@ -24,13 +24,13 @@ struct layer_status_state {
 
 static void set_layer_symbol(lv_obj_t *label, struct layer_status_state state) {
     if (state.label == NULL) {
-        char text[7] = {};
+        char text[8] = {};
 
-        sprintf(text, LV_SYMBOL_KEYBOARD " %i", state.index);
+        snprintf(text, sizeof(text), LV_SYMBOL_KEYBOARD " %i", state.index);
 
         lv_label_set_text(label, text);
     } else {
-        char text[13] = {};
+        char text[14] = {};
 
         snprintf(text, sizeof(text), LV_SYMBOL_KEYBOARD " %s", state.label);
 
@@ -64,4 +64,4 @@ int zmk_widget_layer_status_init(struct zmk_widget_layer_status *widget, lv_obj_
 
 lv_obj_t *zmk_widget_layer_status_obj(struct zmk_widget_layer_status *widget) {
     return widget->obj;
-}
\ No newline at end of file
+}
diff --git a/app/src/display/widgets/output_status.c b/app/src/display/widgets/output_status.c
index da29a95f..7b6f9486 100644
--- a/app/src/display/widgets/output_status.c
+++ b/app/src/display/widgets/output_status.c
@@ -35,7 +35,7 @@ static struct output_status_state get_state(const zmk_event_t *_eh) {
 }
 
 static void set_status_symbol(lv_obj_t *label, struct output_status_state state) {
-    char text[10] = {};
+    char text[20] = {};
 
     switch (state.selected_endpoint.transport) {
     case ZMK_TRANSPORT_USB:
diff --git a/docs/docs/faq.md b/docs/docs/faq.md
index 2100b972..901e9c96 100644
--- a/docs/docs/faq.md
+++ b/docs/docs/faq.md
@@ -57,7 +57,7 @@ For keyboards, this is one of two options:
 
 ### What is a “shield”?
 
-In ZMK, a _shield_ is a _PCB_ or _hardwired set of components_ that when combined with a MCU only [board](#what-is-a-board) like the Proton-C or nice!nano, results in a complete usable keyboard. Examples would be keyboard PCBs like the Kyria or Corne. The _shield_ is usually the big PCB containing all the keys.
+In ZMK, a _shield_ is a _PCB_ or _hardwired set of components_ that when combined with an MCU-only [board](#what-is-a-board), like the Proton-C or nice!nano, results in a complete usable keyboard. Examples would be keyboard PCBs like the Kyria or Lily58. The _shield_ is usually the big PCB containing all the keys.
 
 ### Why _boards_ and _shields_? Why not just “keyboard”?
 
diff --git a/docs/docs/features/modules.mdx b/docs/docs/features/modules.mdx
index e25bc72a..acab84c2 100644
--- a/docs/docs/features/modules.mdx
+++ b/docs/docs/features/modules.mdx
@@ -149,7 +149,7 @@ When [using GitHub Actions to build ZMK](../user-setup.mdx), once you have obtai
 defaultValue="zmk"
 values={[
 {label: 'Default', value: 'zmk'},
-{label: 'Alterative', value: 'alt'},
+{label: 'Alternative', value: 'alt'},
 ]}>
 <TabItem value="zmk">
 
diff --git a/docs/docs/features/split-keyboards.md b/docs/docs/features/split-keyboards.md
index 523f4971..7421d1d6 100644
--- a/docs/docs/features/split-keyboards.md
+++ b/docs/docs/features/split-keyboards.md
@@ -55,7 +55,7 @@ Any changes in ZMK related to split keyboard features might also necessitate doi
 
 Split keyboards with BLE-based split communications (i.e. all officially supported split keyboards) have an internal pairing procedure between the central and each peripheral.
 When the central has an open slot for a peripheral, it will advertise for connections (which will not be visible to non-ZMK devices).
-Then, any peripheral that has not yet bonded to a peripheral will pair to it.
+Then, any peripheral that has not yet bonded to a central will pair to it.
 Similar to how [bluetooth profiles](bluetooth.md) are managed between the keyboard and host devices, the bonding information will be stored with the corresponding hardware addresses of the other keyboard part, on both the central and peripheral.
 
 In practice, this means that your split keyboard parts will automatically pair and work the first time they are all on at the same time.